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a  specification  are  described.  Finally,  some  example 
specifications  together  with  their  generated  Equate-Atlas  program;; 
are  given. 
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Chapter  One 
INTRODUCTION 


1.1  MOTIVATION 

The  software  crisis  of  the  sixties  saw  the  acceptance  of  structured  programming, 
modularity,  and  top  down  design  methodologies  in  building  and  maintaining  software 
systems.  The  underlying  philosophy  behind  these  methodologies  was  that  the  software 
systems  are  complex;  that  they  are  hard  to  understand  and  difficult  to  manage;  and  to  keep 
them  within  manageable  limits,  the  discipline  of  structured  programming  should  be  imposed 
on  the  programmers.  It  reflected  and  still  reflects  the  state  of  software  technology.  The 
requirements  for  systems  are  specified  informally  or  semi  formally  to  the  programming  team, 
which  then  implements  a  system  satisfying  the  requirements.  There  is  a  large  gap  between 
the  specification  language  (generally,  English  for  informal  specifications)  and  the 
implementation  language  (Fortran,  Cobol  etc.),  thus  causing  the  implementation  to  address  a 
lot  of  detail.  This  leads  to  increased  complexity  of  software  which  makes  the  debugging  and 
maintenence  difficult.  The  structured  programming  and  top  down  approach  accepts  this 
complexity  as  unavoidable,  and  tries  to  keep  it  under  control  by  requiring  the  programmer  to 
use  simple  program  structures. 

Continued  growth  in  the  size  of  the  software  systems,  the  demands  of  reliability  and 

programmer  productivity  requires  new  solutions.  It  has  led  to  activity  in  the  field  of,  what  are 

calleds  very  high  level  languages  (VHLL).  These  languages  reduce  the  gap  between  the 

informal  specifications  and  programs.  Sometimes,  these  languages  are  of  sufficiently  high 
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level  that  the  proyram  itself  is  the  specification  satisfying  the  (intuitive  or  mental) 
requirements  Some  of  these  languages,  in  which  order  of  statements  in  programs  is 
immaterial,  are  called  non  procedural  languages.  In  fact,  a  program  in  these  languages  is  so 
unlike  a  program  in  piocedural  languages  that  we  call  it  a  specification .'  Many  of  the  issues 
of  structured  programming  (e.g.  disciplined  used  of  the  control  structme)  no  longer  have  any 
meaning  in  the  context  of  non  procedural  languages,  since  the  specifications  do  not  have  any 
control  structure  The  details  relating  to  the  conlrol  are  no  longer  the  concern  of  the  user,  but 
rather,  are  handled  by  the  compiler  for  the  language. 

Modularity  still  remains  a  useful  and  important  issue  for  large  specifications.  Modu'nrity 
may  be  defined  as  independence  in  compiling  and  composing  of  different  parts  of  a  larger 
specification  It  is  desirable  because  it  simplifies  the  specification  This  simplification  results 
not  only  because  of  reduced  size,  but  also  because,  with  proper  sub  division,  the  smaller 
specifications  represent  logical  sub  units  of  the  larger  specification  Modularity  allows 
incremental  development  of  a  large  specification  It  also  lends  itself  to  easier  modification.  In 
most  cases,  only  a  few  of  the  smaller  specifications  need  to  be  changed  when  the  needs  of 
the  specified  system  evolve  or  change. 

1.2  BACKGROUND: MODEL  AND  NOPAL  SYSTEMS 

Model  and  Nopal  are  non  procedural  languages  developed  at  the  University  of 
Pennsylvania  in  an  attempt  towards  a  simple  yet  powerful  very  high  level  language.  These 
languages  have  no  control  structure,  and  are  based  on  the  familial  notions  of  mathematics. 

'"Specification''  has  also  been  used  in  the  liteialme  to  express  the  'loquiieinents"  of  a  system,  oi  the  set  of 
algebraic  axioms  defining  an  abstract  data  type  etc  Usage  of  the  term  here  should  not  he  confused  with  its  other 
meanings. 
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The  Model  system  [42]  has  been  designed  to  automate  the  generation  of  software  for  data 
processing  applications.  The  first  step  is  to  provide  a  data  processing  requirements.  It 
consists  of  three  main  parts.  The  first  part  is  the  header,  which  consists  of  the  name  of  the 
specification  and  names  of  the  data  bases  The  second  part,  the  data  description,  consists  of 
descriptions  of  the  structure  of  the  source  and  target  data  in  the  specification.  The  source 
data  corresponds  to  the  input  data,  generally  on  sequential  and  indexed  sequential  files;  the 
target  data  refers  to  the  desired  output  files.  The  third  part,  a  set  of  assertions,  specifies  the 
relations  between  the  source  and  target  variables.  There  are  no  control  statements  typical  of 
procedural  high  level  languages,  e  g.  those  that  deal  with  input/output,  loop  control  etc. 

The  Model  processor  analyzes  many  aspects  of  the  specification.  It  checks  for 
ambiguities,  incompleteness  and  inconsistencies  and  issues  appropriate  messages  to  the 
user.  It  also  generates  a  number  of  reports  which  serve  as  the  documentation  for  the 
specification.  The  processor  then  produces  a  sequence  of  execution  for  the  assei lions,  with 
appropriate  loop  control  statements.  Finally,  it  produces  a  PL/I  (or  Cobol)  program. 

The  Nopal  system  [46]  has  been  designed  to  automate  the  generation  of  programs  for 
automatic  testing  of  electronic  circuits.  A  specification  in  Nopal  has  three  major  parts.  The 
first  part  gives  the  test  specification,  the  second  part  the  unit  under  tost  (UUT)  specification, 
and  the  third  part  the  automatic  test  equipment  (ATE)  specification.  These  parts  can  occur  in 
any  order  in  the  specification.  The  test  specification  consists  of  a  number  of  tests  each  of 
which  is  used  to  specify  the  stimuli  to  be  applied,  measurements  to  be  made,  computations  to 
be  performed,  and  diagnosis  to  be  selected.  The  specification  of  the  individual  tests  is 
non  procedural,  and  similarly,  there  is  no  sequence  specified  between  the  tests.  The 
diagnoses  are  normally  selected  based  on  the  outcome  of  tests.  They  are  used  to  isolate 
faulty  components  and  print  appropriate  message  to  that  effect.  The  UUT  and  ATE 
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specifications  are  used  to  specify  the  characteristics  of  UUT  and  ATE. 

The  Nopai  processor,  similar  to  the  Model  processor,  analyzes  the  specification  for 
ambiguity,  incompleteness  and  inconsistency.  It  too  generates  reports  which  serve  as  the 
documentation  for  the  specification  The  processor  produces  a  sequence  of  execution  for 
the  tests,  in  the  ptiase  called  inter  test  sequencing.  It  then  analyzes  each  of  the  tests 
individually  and  generates  a  sequence  for  the  assertions,  conjunctions,  and  diagnoses  in  the 
test  Finally,  when  all  the  problems  are  resolved  it  generates  a  program  in  Equate  Atlas. 

the  issue  of  modularity  is  an  important  one  for  both  the  systems.  At  present  the 
specification  must  be  submitted  as  one  unit  It  leads  to  many  of  Ihe  problems  mentioned  in 
the  previous  section,  and  to  some  very  practical  problems  when  the  processors  for  the 
language  run  out  of  address  space  during  execution. 

1.3  CONTRIBUTIONS 

This  dissertation  examines  and  proposes  the  approach  of  abstract  data  types  for 
modularity  in  these  languages,  and  describes  the  implementation  for  the  Nopal  language. 
The  following  are  the  contributions  of  this  work: 

It  has  led  to: 

1.  the  definition  of  a  scheme  for  modularity  in  non  procedural  languages, 

2.  a  novel  way  to  define  the  abstract  data  types,  namely,  by  means  of  the 
non  procedural  specification,  and 

3.  automatic  generation  of  program  modules  that  correspond  to  respective 
specification  of  the  abstract  data  types, 

Abstract  data  types  provide  a  non  procedural  way  to  introduce  modularity.  Variables  in  the 
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specification  can  be  declared  to  be  of  abstract  type,  in  which  case  they  may  be  operated  upon 
by  a  restricted  set  of  functions.  The  definition  of  an  abstract  data  type  along  with  the  set  of 
functions  is  given  separately  by  means  of  a  "module".  The  specification  of  a  module  is  given 
non  procedurally,  leading  to  the  dual  contributions  (1)  and  (2). 

Finally,  the  above  ideas  on  modularity  are  used  in  the  Nopal  system  The  Nopal  language 
has  been  developed  to  generate  programs  for  testing  of  electronic  circuits.  The  abstract  data 
type  facility  is  used  to  define  the  devices  for  testing.  My  work  on  the  above  system  has  been 
on  the  development  and  completion  of  the  original  Nopal  system  [/].  and  implementation  of 
the  idea  of  abstract  data  types. 


1 .4  ORGANIZATION  OF  Ti  IE  DISSERTATION 

This  dissertation  is  divided  into  six  chapters.  Introduction  is  given  in  this  chapter,  followed 
in  Chapter  2  by  a  survey  of  past  work  in  the  fields  of  non  procedural  languages  and  abstract 
data  types. 

Chapter  3  contains  the  use  and  spec  dication  of  the  abstract  data  types  in  a  non  procedural 
languages  independent  of  either  Mod  or  Nopal.  The  use  and  specification  of  "modules"  is 
described.  Formal  semantics  of  the  modules  is  given  and  similarity  of  the  module 
specification  with  algebraic  axioms  is  shown. 

In  Chapter  4  the  language  Nopal  ini  >rporating  the  above  ideas  is  described.  Features  of 
Nopal  for  specification  of  autuma  c  testing  of  electronic  circuits  are  presented. 
Implementation  of  Nopal  is  given  in  Ch.  pier  5,  and  the  various  phases  of  the  Nopal  processor 
are  described.  Examples  of  Nopal  specifications  and  the  reports  generated  by  the  Nopal 
processor  are  given  in  the  Appendix. 
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2  SURVEY  OF  REL A1  ED  LITERATURE 

Conclusions  and  ideas  for  future  work  are  suggested  in  Chapter  6. 


I 
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Chapter  Two 

SURVEY  OF  RELATED  LITERATURE 

2.1  SURVEY  OF  NON-PROCEDURAL  LANGUAGES 

Looking  back  at  the  development  of  computers  we  find  a  hierarchy  of  computer 
programming  languages  The  assembly  level  languages  form  the  lowest  level  and  the  higher 
level  languages  such  as  Fortran,  PL/I,  Algol  etc.  form  the  next  higher  level.  Both  classes  of 
languages  are  characterized  as  (a)  procedural,  and  (b)  domain  independent.  They  are 
procedural  because  the  individual  statements  are  prescriptive  and  a  program  in  the  language 
consists  of  a  sequence  of  such  statements  These  languages  may  be  used  in  widely  varied 
application  areas  and  hence  are  called  domain  independent. 

The  next  higher  level  languages  are  referred  to  as  very  high  level  languages  (VHLL)  and 

they  may  be  sub  divided  into  two  groups  The  first  group  consists  of  languages  which  are 

domain  dependent  e  g.  Business  Definition  Language  (BDL)  [21];  the  second  group  consists 

of  domain  independent  languages  with  facilities  to  describe  higher  level  concepts  which  allow 

the  omission  of  many  details  Examples  of  this  group  are  SETL  [29]  which  allows 

manipulation  of  sets  and  relations,  APL  [27]  which  has  many  convenient  operators  for 

matrices,  LISP  [57]  which  works  on  lists  etc  In  the  second  group  there  are  many  languages 

that  are  descriptive  and  are  devoid  of  any  control  facilities  This  class  of  languages  is  referred 

to  as  non  procedural,  because  a  "program"  in  these  languages  does  not  give  a  prescriptive 

sequence  to  be  followed,  but  rather  defines  variables  and  their  values  in  a  sequence  free 

manner.  A  "program"  in  these  languages  is  so  unlike  that  in  procedural  languages  that  we 

.7 
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call  it  by  a  different  name:  "specification"  as  mentioned  earlier  in  Chapter  1 . 

The  goal  of  the  VHLLs  is  to  allow  the  user  to  express  his  or  her  problem  directly  in  these 
languages,  thus  leading  to  automatic  programming  systems  which  accept  the  specification 

and  generate  a  program  corresponding  to  it  [42] 

"The  ultimate  expectation  for  automatic  programming  may  be  visualized  as  a 
user  (no  longer  a  programmer )  making  a  few  simple  statements,  to  which  the 
automatic  programming  system  responds  by  spewing  out  a  program  of  several 
hundred  statements,  already  correct  and  satisfying  the  user  s  intentions." 

Non  procedural  languages  have  been  around  for  more  than  a  decade  ( [6|.  |2G|.  [4/],  [52], 
etc  )  and  they  continue  to  he  of  current  interest  ( [  1  ].  [4],  [25],  [42]  etc.). 

One  of  the  early  attempts  by  Teslei  [52]  defined  lists  and  operations  on  lists  An  important 
operation  was  PRECEDING,  which  was  used  to  express  the  relationship  of  the  current  item  in 
the  list  to  the  preceding  item  in  the  same  list  or  some  other  list  Tina  language  was  restrictive 
because  recurrence  relations  between  items  in  lists  could  be  specified  using  only 
PRECEDING.  Some  of  the  other  early  languages  were  interpreted  and  hence  slow  in  time  and 
inefficient  in  memory  space. 

More  recently,  LUCID  has  been  designed  as  a  formal  system  in  which  programs  can  be 
written  and  their  proofs  carried  out  "The  proofs  are  easy  to  follow  and  straight  forward  to 
produce  because  the  statements  in  a  LUCID  program  are  simply  axioms  from  which  proof 
preceeds  by  conventional  reasoning  [1]."  Variables  and  their  history  of  values  can  be 
defined  The  history  is  defined  as  a  sequence  of  values  using  the  primitives  FIRST  and  NEXT. 
They  essentially  allow  the  specification  of  one  level  loops  To  allow  nested  loops,  a  function 
called  LATEST  is  introduced.  However,  it  clutters  up  the  program:  consequently.  BEGIN  END 
blocks  to  nest  iterations  are  included  in  the  language. 
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The  limitations  of  the  LUCID  language  are  the  absence  of  arrays  or  any  compund 
structures  and  the  use  of  NEXT  to  define  relationships  between  sequences  of  values.  The 
latter  implies  that  the  relationships  be  known  in  advance  at  program  writing  time,  and  cannot 
be  computed  at  run  time  For  example,  it  is  not  possible  to  specify  that  the  current  element 
depends  on  the  klh  previous  element,  where  k  is  computed  at  execution  time. 

Non  procedural  languages  Model  [42]  [48|  [50]  [39]  and  Nopal  [7]  [4 1  ]  1 56]  [46]  allow 
relationships  between  array  variables  to  be  defined  explicitly  by  means  of  indices.  This  makes 
the  languages  richer  than  LUCID.  At  the  same  time,  they  are  compiled  rather  than 
interpreted.  A  brief  introduction  to  them  has  been  given  in  Chapter  1. 

A  recent  proposal  by  Kessels  [30]  is  to  mix  procedural  and  non  procedural  approaches.  In 
his  approach,  "block"  is  the  basic  struc  which  indicates  the  scopes  of  names,  as  well  as 
the  mode  (non  procedural  or  sequential).  A  "valued  block"  has  a  set  of  values.  Besides 
these,  ther  are  multi  state  blocks  which  retain  information  after  the  exit  from  the  block.  Many 
of  these  features  serve  to  increase  the  complexity  of  the  language,  and  make  it  difficult  to 
learn  and  use 

A  number  of  domain  dependent  systems  have  been  proposed  Some  of  them  are 
described  below. 

Business  Definition  Language  [21  ]  is  a  very  high  level  domain  dependent  language.  It  is 
aimed  at  the  problems  of  business  data  processing.  It  assumes  a  model  of  the  processes 
involved  in  the  manual  methods  used  in  businesses  and  tries  to  mimic  those  There  are  three 
components:  one  for  defining  the  business  forms,  one  for  describing  the  business 
organization,  and  one  for  writing  calculations  Using  a  graphics  screen  the  forms  may  be 
defined.  They  serve  both  as  input  and  output,  as  well  as  internal  representatior.  of 
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infoimation.  These  documents  can  be  routed  to  different  parts  of  the  organization  or  stored 
in  files.  Computations  can  be  defined  on  the  elements  in  the  forms.  Essentially,  it  is  a  tabular 
language  with  special  constructs  to  represent  the  domain  of  business. 

PSI  system  developed  at  Stanford  [  16]  uses  a  model  based  appoaoh  like  ODL.  However,  it 
has  provision  for  incorporation  of  an  independent  domain  expert  module  Information  about 
objects  and  their  relationships  in  the  domain  is  included  in  the  module,  thus  freeing  the  user 
from  defining  commonly  used  terminology.  The  modules  may  be  changed  depending  on  the 
domain. 

PROIOSYSTEM  I  has  been  developed  by  the  Automatic  Program  Generation  Group  at 
M  l  T  [4!i|  It  consists  of  two  parts:  The  top  part  consists  of  a  man  machine  interface,  a 
knowledge  base  on  business  management  etc  The  bottom  part  obtains  a  data  processing 
specificalion  from  the  top  part,  performs  system  design,  and  generates  PL/I  code.  The 
specification  language  used  is  SSL  winch  is  non  procedural  and  resembles  Model. 

There  are  other  examples  of  domain  dependent  systems,  most  notably.  APS  developed  at 
University  of  Southern  California  at  LS  I  (3j  SGA  [62]  etc. 


2.2  SURVEY  OF  ABSTRACT  DATA  TYPE  SPECIFICATION 
TECHNIQUES 

Data  abstraction  has  been  identified  as  a  widely  useful  program  unit  by  recent  work  in 
programming  methodology.  It  has  also  been  identified  to  be  a  unit  for  which  formal 
specifications  can  b<*  written  easily.  It  can  serve  as  a  basis  for  modularity  Consequently, 
work  related  to  data  abstraction  or  abstract  data  types  is  reviewed  here. 
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There  are  Iwo  approaches  for  giving  the  formal  specification  of  abstract  data  types.  The 
specification  can  be  given  either  by  means  of  an  abstract  model,  or  implicitly  via  descriptions 
of  operations  on  the  data  types  [35]  In  following  the  first  approach,  the  behaviour  is  actually 
defined  by  giving  an  abstract  implementation  in  terms  of  another  data  abstraction  or 
mathematical  discipline  In  the  second  approach,  the  class  of  objects  is  determined 
inductively  from  the  operations.  Usually,  it  is  the  smallest  set  closed  under  the  operations. 

Liskov  and  Zilles  [35]  have  further  classified  the  approaches  for  specification  of  abstract 
data  types  into  five  categories  The  classification  is  based  on  the  method  used  for 
specification,  e  g. 

1 .  use  of  a  fixed  domain  of  formal  objects,  such  as  sets,  graphs  or  arrays; 

2.  use  of  an  appropriate  known  formal  domain; 

3.  use  of  a  state  machine  model; 

4.  use  of  an  implicit  definition  in  terms  of  axioms;  and 

5.  use  of  an  implicit  definition  in  terms  of  algebraic  relations; 

to  specify  abstract  data  types.  The  first  two  categories  use  the  first,  i.e.  abstract  model 
approach,  while  the  remaining  use  the  second,  i.e.  implicit  definition  approach.  Some 
examples  belonging  to  each  of  the  categories  are  given  below. 

In  the  first  category,  a  fixed  domain  of  formal  objects  is  used  to  provide  a  high  level 
implementation  of  the  desired  abstract  data  type.  For  example,  V  graphs  were  used  by  Earley 
[1 1]  to  represent  instances  of  data  structures  Operations  on  the  data  structure  are  specified 
either  by  expressions  written  in  terms  of  primitive  V  graph  operations,  or  by  means  of  pictures 
of  V  graph  transformations. 

An  appropriate  known  formal  domain  can  be  chosen  to  give  the  high  level  representation 
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for  the  abstraction  Generally,  this  is  some  established  mathematical  domain.  Hoare  has 
used  this  approach  to  specify  sets  and  subsets  of  integers  [24],  The  advantage  of  this 
approach  is  ttiat  a  body  of  knowledge  is  available  about  the  formal  domain:  on  the  other  hand, 
it  may  not  be  suitable  fot  representing  the  abstraction. 

Parnas  |38|  has  develops*! I  a  technique  and  notation  for  viewing  the  abstraction  as  states 
of  an  abstract  state  machine. 

Use  of  axiomatic  descriptions  to  specify  the  abstractions  falls  under  the  fourth  category. 
The  axioms  define  equivalence  classes  ovei  the  set  of  all  expressions  II  the  set  of  axioms  are 
well  chosen,  the  equivalence  classes  are  unique.  The  axiomatic  specifications  are  minimal 
and  widely  applicable,  however,  they  are  deficient  with  respect  to  comprehensibility. 

Recently,  an  algebraic  specification  technique  based  on  the  algebraic  construction,  known 
as  "presentation",  has  emerged  as  a  popular  one.  The  algebraic  axioms  are  easier  to 
understand  than  the  general  axiomatic  specifications,  and  they  too  are  representation 
independent  An  algebraic  specification  has  two  components:  syntactic  and  semantic.  The 
syntactic  component  gives  the  domains  and  ranges  of  the  operations  on  the  abstract  data 
type.  The  semantic  component  consists  of  set  of  algebraic  axioms  in  the  form  of  equations, 
which  relate  the  operations  to  each  other  An  implementation  may  also  be  given  for  the  data 
types.  "An  implementation  of  an  abstract  data  type  is  an  assignment  of  meaning  to  the  values 
and  operations  in  terms  of  the  values  and  operations  of  another  data  type  or  set  of  data 
types  [18)."  A  correct  implementation  must  satisfy  the  algebraic  axioms  The  data  types  used 
in  the  implementation  are  also  specified  by  means  of  axioms;  and  their  implementation  may 
again  be  specified  if  they  are  abstract  types.  The  proof  of  the  correctness  of  the 
implementation  requires  showing  that  each  of  the  algebraic  axioms  for  the  data  type  is 
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satisfied  when  the  implementations  are  substituted  in  the  axioms.  The  definition  of  equality 
interpretation  for  the  implementation  is  needed  for  the  proof.  A  general  principle  used  in  the 
proof  is  that  of  data  type  induction.  It  means  proving  some  invariant  property  of  the  data  type, 
and  involves  establishing  the  base  step  and  the  induction  step. 

Goguen,  Thatcher  and  Wagner  have  described  an  initial  algebra  approach  to  the 
specification,  correctness,  and  implementation  of  the  abstract  data  types  [  14).  They  describe 
a  first  order  language  (or  X- algebra)  using  sorts  and  signature  over  sorts.  They  then  define  a 
category  C  of  2  algebras  to  consist  of  2  algebras  together  with  all  the  X  homomorphisms. 
Alg  v  is  defined  as  a  [53] 

"universe  of  discourse  where  the  process  of  axiomatizing  on  the  data  types  is 
going  on.  In  particular,  the  free  algebra  in  Alg ^  provides  a  language  in  which  to 
write  down  the  axioms,  and  their  homomorphisms  tell  us  how  to  interpret  the 
axioms. " 

Given  the  above  algebra,  the  concepts  of  presentation  and  initial  algebra  are  introduced;  it 
is  proved  that  the  initial  algebras  are  isomorphic  leading  to  the  main  result:  "An  abstract  data 
type  is  the  isomorphic  class  of  an  initial  algebra  in  a  category  of  ^  algebras."  It  provides  a 
rigorous  mathematical  basis  for  the  specification  techniques  using  axioms. 


2.3  LANGUAGES  SUPPORTING  ABSTRACT  DATA  TYPES 

The  use  of  axiomatic  specifications  is  still  far  from  practicable  It  involves  fair  degree  of 
mathematical  expertise  to  formulate  the  axioms  and  to  check  their  consistency  and 
completeness  Consequently,  the  practical  languages  which  allow  the  definition  of  abstract 
data  types  are  still  based  on  the  abstract  model  approach  (which  includes  categories  (1),(2), 


and  (3))  described  in  the  previous  section. 
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CLlJ  language  was  developed  at  M  I  T  [:M|  to  support  the  use  of  ab.sli  actions  in  program 
construction  it  supports  three  types  of  abstractions:  procedural  control,  and  data  It  has  a 
mechanism,  called  "cluster"  to  define  the  data  abstraction  A  cluster  is  used  to  define  the 
r-  pivsi  station  uf  a  nata  type  and  the  set  of  operation;;  winch  can  b pmformod  on  it  The 
representation  ma/  he  given  using  variables  whose  data  type.;  are  again  defined  in  other 
clusters  In  sur  li  cases,  references  are  associated  with  these  vaiiables.  and  the  actual  data  is 
stoied  in  the  clusters  The?  only  way  to  access  or  modify  tnis  data  is  by  means  of  operations 
defined  in  flit*  c  luster  for  the  appropriate  abstrar  t  data  type. 

In  lire  implementation,  the  variables  wine  li  are  defined  to  be  of  abstract  data  type  actually 
store  references  to  data,  while?  tire  data  and  its  representational  details  are  given  in  the 
cluster  it  does  away  with  explicit  manipulation  of  pointers,  yet  allows  an  efficient 
implementation  However.  it  causes  a  change  in  semantics  ol  the  haditional  assignment 

statement  In  the  example: 

l!  -  Ml  W: 

A  -  B  : 

MOP  I  I  Y  ( I! )  ; 

the  variables  A  and  f>  an  of  ;.>n-  im.tr  i  t  type  which  has  operations  NEW  and  MODIFY 
defined  in  a  cln:.i*.n  The  fn  .1  •  f  s'-  ru-  rit  .  hi;  ns  B  to  In?  defined  but  since  the  data  type  is 
defined  m  a  cluster  u  amply  ti .r . -s  a  (•■!•  rence  to  the  data  In  the  second  statement  the 
same  reference  is  stored  in  A  ihe  problem  is  caused  by  the  third  statement  Modification  of 
the  structure  pointed  to  by  b  cause's  the  modification  of  A.  as  a  side  effect 

The  above  suggests  two  alternatives:  either  the  notion  that  A  and  B  are  of  abstract  data 
type  should  be  abandoned  and  they  should  simply  be  declared  to  be  ol  pointer  type:  or  the 
semantics  of  the  assignment  statement  be  redefined.  In  Cl  U.  the  latter  appioueh  is  chosen 
anci  the  assignment  statement  is  defined  to  mean  "renaming".  In  the  example,  the  second 
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statement  will  be  taken  to  mean  that  A  is  the  name  of  the  same  object  as  denoted  by  B.  In  a 
language  which  is  side-effect  free  the  above  problem,  of  course,  does  not  arise. 

Concurrent  Pascal  has  been  developed  by  Brinch-Hansen  [5]  for  the  writing  of  concurrent 
programs.  It  allows  the  definition  of  monitors.  A  monitor  defines  a  type  whose  instances  may 
be  created.  The  data  associated  with  an  instance  can  be  accessed  using  that  particular 
instance  of  the  monitor  This  restriction  disallows  recursive  definition  of  monitors.  Moreover, 
operations  defined  in  the  monitor  can  operate  on  variables  only  in  one  particular  instance  of 
the  monitor.  These  restrictions  may  be  justified  for  concurrent  programming,  however,  the 
language  is  not  discussed  any  furthei  here,  due  to  those  severe  limitations. 


Chapter  Three 

ABSTRACT  DATA  TYPES  IN  A 


NONPROCEDURAL  LANGUAGE 

3.1  INTRODUCTION 

This  chapter  describes  modularity  in  a  simple  non  procedural  programming  language 
based  on  mathematical  equations,  through  the  use  of  abstract  data  types.  The  presentation  is 
independent  of  the  Model  or  Nopal  systems,  referred  to  previously.  The  objective  in  this 
Chapter  is  to  keep  the  language  simple  so  as  to  convey  the  concepts  without  being 
encumbered  by  details. 

Section  3.2  introduces  the  non  procedural  language.  Alternative  aproaches  to  modularity 
are  discussed  in  section  3  3  Use  of  abstract  data  types  is  described  in  section  3.4;  and  their 
specification  using  modules  is  given  in  sections  3.5,  3.6  and  3.7.  Finally,  the  semantics  of 
modules  is  given  in  Section  3.8,  followed  by  a  summary  in  Section  3.9. 

In  short,  this  chapter  describes  the  design  rationale  of  abstract  data  types  for 
non- procedural  languages  based  on  mathematical  equations. 


3.2  ASIMPLE  NON-PROCEDURAL  LANGUAGE  BASED  ON 
EQUATIONS 

A  specification  in  a  non  procedural  language  basically  consists  of  two  kinds  of  statments: 
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1  declaration  of  variables  (including  an  ays  and  structures)  and  their  data  types, 
and 

2  mathematical  relations  (also  called  assertions)  between  the  variables. 

A  variable  can  tahe  a  value  belonging  to  the  set  specified  try  us  data  type.  The  data  type  o( 
a  variable  can  either  tie  declared  explicitly  or  be  determined  from  its  use.  It  is  immaterial  to 
th<>  specification  where  the  variables  are  stored,  i  e.  in  main  memory  or  secondary  memory. 
1  lie  basic  data  stun  tuie  m  the  ianguage  is  the  array  Variables  or  structures  may  be  declared 
to  be  arrays  A  sequential  file  is  consideied  to  tie  an  array  of  records 

Asset  lions  are  essentially  equations  which  define  relationships  between  variables.  A 
vaunble  can  have  only  one  value  as  in  mathematics  Each  asset tion.  in  fact,  defines  the  value 
of  a  vai mbits  The  assertions  can  be  composed  by  the  user  in  any  order  because  they  specify 
relations,  which  do  not  have  any  temporal  meaning  associated  with  them. 

By  the  use  of  free  subscripts,  a  single  asset tion  can  define  the  value  of  an  entire  array. 
Identifiers  corresponding  to  the  free  subscripts  can  be  declared  The  notion  and  use  of  free 
subscripts  is  similar  to  that  in  mathematics.  Tor  example,  let  "E"  be  an  array  variable,  and  "I" 

a  free1  subscript,  then  the  assertion: 

F (  I )  =  IF  1  =  1  THEN  1 

ELSE  I *F ( I - 1 ) 

defines  the  value  of  the  entne  array  F  Each  element  of  Ihe  array  F  is  defined  in  terms  of  the 
previous  one.  except  for  the  first  element  which  is  defined  to  be  1 . 

In  the  above  example,  the  size  of  the  array  F  is  not  specified,  and  hence  is  possibily  infinite. 
The  size  can  be  specified  in  essentially  two  ways: 

1  An  upper  bound  can  be  declared  for  Ihe  subscript  I;  or 

2  A  special  array  of  the  same  dimensions  and  sizes  as  F  can  be  defined,  which 
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identifies  the  size  for  the  rightmost  dimension  of  F.  This  special  array  is  called  the 
end  array.  F  is  defined  upto  the  largest  index  such  that  the  corresponding 
element  in  the  special  array  is  true,  and  all  elements  of  lower  index  are  false.  Its 
use  is  illustrated  by  means  of  an  example: 

END. F( I)  =  IF  1=4  THEN  TRUE 

ELSE  FALSE; 

The  above  causes  an  array  F  to  be  of  size  4.  In  other  words,  an  array  variable  F  is 
defined  for  as  many  elements  until  and  including  the  first  true  element  of  END.F. 

Certain  rules  govern  the  usage  of  subscripts.  These  have  been  designed  so  that  the 
specification  can  be  compiled  rather  than  interpreted.  A  subscript  can  occur  in  one  of  three 
forms: 

1 .  a  subscript  term  e.g.  I  in  F(l); 

2.  an  expression  of  the  form  (l-k)  where  k  is  a  positive  integer,  e  g.  (11)  in  F(l-1);  and 

3.  another  variable  or  subscripted  variable ,  e  g.  G(l)  in  F(G(I)). 

For  a  subscripted  variable  which  occurs  on  the  left  hand  side  of  the  equation,  ils  subcripts 
must  be  in  the  first  form.  This  makes  the  consistency  analysis  simpler. 

The  above  is  the  essence  of  a  non  procedural  language  using  mathematical  equations. 
There  are  many  additional  features  in  the  Model  language  to  handle  file  organization,  and  in 
the  Nopal  language  for  fault  isolation  in  testing  of  physical  systems.  A  processor  for  such  a 
language  analyzes  the  specifications  for  consistency,  completeness  and  non  ambiguity;  and 
if  successful,  generates  a  program  in  a  high  level  language.  By  consistency  we  mean  that  the 
variables  are  defined  only  once,  and  by  completeness  that  the  variables  are  defined  at  least 
once.  In  the  generated  program,  the  variables  should  be  defined  before  they  are  referenced. 
This  analysis,  which  is  non  trivial  when  free  subscripts  are  used,  is  described  with  respect  to 


the  Nopal  system  in  Chapter  5. 
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3.3  APPROACHESTO  MODULARITY 

Need  for  modularity  has  been  discussed  m  Chapter  1.  As  discussed  earlier,  it  means 
subdividing  a  problem  into  smaller  specifications,  and  compiling  each  of  the  specifications 
sepeiately.  A  number  of  alternative  approaches  are  possible  to  achieve  modularity  in 
non  procedural  languages.  Some  of  them  are  described  below. 

The  simplest  approach  is  to  divide  a  large  specification  into  smaller  specifications  which 
communicate  through  commonly  named  vaiiables.  The  aggiegate  of  sub  parts  is  exactly 
equivalent  to  the  total,  obtained  by  simply  putting  the  sub  pads  together  and  forming  one 
large  specification. 

In  a  different  approach,  each  sub  part  represents  a  specification  ol  a  function,  and  these 
functions  may  be  used  in  other  sub  parts  In  this  approach,  the  functions  may  be  specified 
once  and  used  many  tilths  resulting  in  a  more  compact  overall  specification.  A  judicious 
choice  of  functions  may  also  correspond  to  a  decomposition  of  the  specification  at  the  logical 
or  "conceptual"  level. 

Still  another  approach  utilizes  the  idea  of  data  abstaction.  In  this  approach  a  sub  part 
specifies  an  abstract  data  type  and  the  functions  which  are  allowed  to  operate  on  variables  of 
the  data  type  The  data  type  can  now  be  used  in  other  sub  parts.  In  othei  words,  variables  in 
other  sub  parts  can  be  declared  to  be  of  the  defined  data  type  and  be  opeiated  upon  by  the 
specified  functions  This  approach  has  the  advantage  similar  to  the  functional  approach, 
namely,  that  a  data  type  specified  once  in  a  sub  part  may  be  used  many  times  in  other 
sub  parts. 

A  procedure  m  a  programming  language  accomplishes  an  action  (or  performs  a  sequence 


of  steps).  A  procedure  is  used  knowing  "what"  it  accomplishes  without  knowing  "how”  it 
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accomplishes  it,  and  similarly  it  is  defined  knowing  "what"  it  is  supposed  to  accomplish 
without  knowing  "how"  it  will  be  used.  Thus  the  abstraction  separates  use  from  definition 
and  introduces  modularity.  In  a  similar  fashion,  a  data  type  is  specified  independent  of  its  use. 
It  represents  a  set  of  objects  which  satisfy  certain  properties,  and  frequently,  these  objects 
correspond  to  the  user's  problem  domain,  e  g.  stacks,  tokens,  sets  etc  A  variable  of  the  said 
data  type  represents  one  of  these  objects  and  allows  us  to  express  relationships  directly 
among  these  objects  in  a  non  procedural  specification.  Thus  it  also  makes  the  specification 
closer  to  the  terminology  of  the  problem. 

Another  advantage  oi  this  approach  is  that  the  representation  for  the  variables  belonging 
to  abstract  types  need  not  be  known  while  writing  the  specification.  This  allows  the 
representation  of  a  data  type  to  be  modified  without  affecting  its  use.  The  representation  of  a 
data  type  is  specified  by  means  of  a  sub  part  defining  the  data  type,  and  can  be  changed  by 
changing  that  sub  pad  alone. 

In  light  of  the  above  advantages,  this  latter  approach  to  modularity  is  adopted  in  this 
dissertation.  (Another  motivation  for  chosing  the  latter  approach  is  that  it  provides  a 
convenient  way  to  represent  devices  for  testing  in  the  Nopal  system.)  It  should  be  recognized 
that  the  sub  part  specifying  the  data  type  allows  the  funtions  which  can  operate  on  the  data 
type  to  be  clustered  together.  The  use  of  this  abstraction  serves  as  the  guiding  principle  for 
clustering  of  the  functions  We  hope  to  illustrate  below  that  this  is.  indeed,  a  natural  way  to 
modularize  non  procedural  languages, 
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3.4  USEOF  ABSTRACT  DATA  TYPES 

Eacti  variable  m  a  non  procedural  specification  has  a  data  type  which  gives  the  set  of  its 
possible  values  The  data  type  of  a  vattable  can  be  elementary  (i  e  one  defined  by  the 
language  e  g  real,  integer,  character  etc.)  or  can  be  one  of  the  abstract  types. 

An  abstract  data  type  must  be  specified  urn  procedurally  by  means  of  a  specification 
called  the  m.ltiU  for  that  data  typo  Just  as  a  variable  of  the  elementary  data  type  can  be 
operated  upon  b,  the  functions  for  the  data  type.  e  g  functions  *  ',  /  for  the  integers,  a 

variable  of  the  abstract  data  type  can  only  be  operated  upon  by  the  set  of  functions  defined  in 
live  corresponding  module. 

Variables  can  occur  m  assertions  as  defined  below.  Assertions  define  the  relationships 

between  the  variables  An  assertion  is  of  the  form: 

^  i  fl  i  •  ^i)|)  ~  r(l  |  •  l(|  i .  A , .  .  An) 

where  A,.  An  are  names  of  array  variables.  I,.  Idl  are  subscripts  foi  dl  dimensional  array 
variable  A,,  and  r  denotes  the  expression  formed  using  function  symbols,  subscripts  and 
array  variables. 

Expressions  are  formed  using  notation  familiar  in  mathematics  Informally: 

t  An  array  variable  followed  by  a  list  of  subscript  expressions  is  an  expression,  and 
tire  data  type  of  tire  variable  gives  the  set  to  which  the  value  of  the  expression 
belongs. 

2  A  function  symbol  follower!  by  expiessioris  in  parenthesis  is  an  expression.  The 
data  types  ol  the  expressions  should  match  the  domains  of  the  function  symbol. 

The  data  type  of  the  new  oxpiessinn  former)  is  the  range  (as  in  mathematics)  of 
the  function  The  expression  defines  a  mapping  from  the  domains  to  the  range  of 
the  function 

3.  Symbols  +  .  .  *.  /  denote  the  functions  for  addition,  subtraction,  multiplication 

and  division:  and  they  may  be  used  as  infix  operators  Similarly,  the  function 
if  then  else  (cond.  x,  y)  with  three  arguments  can  be  written  in  its  familiar  form:  if 


I 
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cond  then  x  else  y. 

Data  types  place  restrictions  on  the  ways  in  which  expression  can  be  combined  to  form  new 
expressions  In  particular,  the  data  types  of  the  arguments  of  a  function  must  match  the 
domains  of  the  function. 

There  is  no  distinction  in  the  use  of  elementary  and  abstract  data  types.  The  user  of  the 
language  once  provided  with  a  set  of  data  types  and  the  functions  which  can  be  performed  on 
them  may  use  the  given  set  of  data  types  without  ever  knowing  which  are  elementary  and 
which  abstract.  The  use  of  the  abstract  data  types,  therefore,  does  not  require  any  new 
meaning  to  be  given  to  variables  or  assertions  in  the  non  procedutal  language. 

3.5  SPECIFICATIONOF  ABSTRACT  DATA  TYPES 

This  section  introduces  the  concept  of  a  module  for  the  specification  of  the  abstract  data 
types  The  specification  of  an  abstract  data  type  is  independent  of  its  use.  It  is  specified 
non  procedurally  within  the  framework  of  the  language  intrduced  in  section  3.2.  The  module 
specification  can  be  analysed  for  inconsistency,  incompleteness,  and  ambiguity,  independent 
of  other  module  specifications.  In  particular,  the  variables  in  the  module  are  single  valued, 
subscripts  are  consistently  used,  and  are  independent  of  the  subscripts  and  dimensions  in 
other  module  specifications.  Finally,  as  will  be  shown  later,  the  generated  program  supports 
the  use  of  variables  of  the  defined  abstract  type  in  other  modules. 

A  module  consists  of:  (1)  a  header  ■  which  gives  the  name  of  the  abstract  data  type,  (2) 
data  declarations  which  give  the  representation  for  the  abstract  data  type,  and  (3) 
module-functions  (modfuns  for  short)  -  which  specify  the  functions  which  can  operate  on  the 
abstract  data  type  being  specified  by  the  module.  The  function  specification  consists  of 
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assertions,  including  formal  paramaters  and  return  value. 

A  module  named  say  ADT,  specifies  a  representation  for  an  abstract  data  type  ADT.  By 
rop'Psentntion  is  meant  the  components  of  a  data  type.  The  word  "representation",  rather 
than  the  word  "data  structure",  is  used  because  the  components  themselves  can  be  abstract, 
in  which  case  ttiey  are  specified  by  means  of  other  modules  A  modfun  may  return  a  value  of 
type  ADT.  in  which  case  the  value  is  defined  by  defining  Ihe  value  of  variables  in  the 
representation.  This  is  done  by  means  of  assertions  in  the  body  of  Ihe  modfun  If  the  value  is 
specified  using  the  formal  parameters  of  the  modfun.  then  the  modfun  specifies  the 
relationship  between  the  formal  parameters  and  the  value  returned.  If  one  of  the  parameters 
is  of  type  ADT  its  representation  is  accessible  in  the  module  ADT  and  can  be  used  in  defining 
the  return  value. 

In  general,  the  return  value  of  a  modfun  may  hr;  of  any  arbitrary  data  type  Appropriate 
function  must  be  used  to  define  the  return  value. 


3.6  ANEXAMPLE  -  STACK 

The  ideas  presented  in  the  previous  section  are  illustrated  by  means  of  an  example  in  this 
section  The  syntax  of  assertions  has  already  been  explained;  the  syntax  of  the  declarations 
is  somewhat  like  Pascal  and  PL /I  The  subscripts  are  declared  by  means  of  a  statement  of  the 
form: 

<subs>  IS  A  SUBSCRIPT; 
where  <subs>  is  the  name  of  the  subscript. 

The  example  chosen  is  stack  of  integers  It  has  four  modfuns.  Their  domains  and  range 


are; 
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Emptystack:  -+  stack 
Push:  stack  *  integer  stack 
Pop:  stack  ->  stack 
Top:  stack  -*  integer 


The  emptystack  maps  from  null  domain  to  an  empty  stack;  Push  maps  a  stack  S  and  integer  X 
to  a  stack  whose  top  element  is  X  and  the  remaining  part  is  the  same  as  stack  S;  Pop  maps  a 
stack  S  to  another  stack  which  is  the  same  as  S  except  wilh  the  top  element  removed;  and 
Top  maps  a  stack  S  to  an  integer  X  such  that  X  is  the  same  as  the  top  element  of  S 

The  above  is  an  informal  description  of  stack  in  English.  The  module  STACK  gives  the 
formal  specification  of  stack  and  its  functions.  The  specification  captures  the  concept 
expressed  informally  above  and  makes  it  precise.  (The  formal  semantics  of  the  module  is 
discussed  in  Section  3.8.) 


Consider  the  following  example  having  an  array  A  of  stacks.  Each  of  the  elements  of  the 


array  A  is  a  stack  onto  which  integers  from  arrays  P  and  O  are  pushed. 

MAIN  EX1 ; 

DCL  A:STACK  ARRAY(IO), 

P,Q: INTEGER  ARRAY  (10); 

R: BOOLEAN  ARRAY  (10); 

I  IS  A  SUBSCRIPT; 

A( I )  =  IF  1  =  1  THEN  EMPTYSTACK 

ELSE  IF  R( I )  THEN  PUSH(A( I-l).P(I-l)); 

ELSE  PUSH ( A( I-l).Q(I-l)); 

/*  ARRAYS  P,Q,R  ARE  ASSUMED  TO  BE  DEFINED  ALREADY.  •/ 

END  EX1 ; 


The  STACK  module  is; 
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MODULE  STACK; 

DCL  1  STACK:  RECORD. 

2  TOPZ :  INTEGER, 

2  Z:  INTEGER  ARRAY ( 100) ; 

J  IS  A  SUBSCRIPT; 

MODI  UN  PUSH( S : STACK ,  X: INTEGER)  RETURNS  (S1:STACK); 
SI. TOPZ  =  S .TOPZ  +1; 

S1.Z(J)  =  IF  J<  =  S  .  TOPZ  THEN  S.Z(J) 

ELSE  X; 

END . S 1 . Z ( J )  =  ( J  =  S1 .TOPZ) 

END; 

MODERN  POP(S :STACK)  RE  I  URNS  (S1:STACK); 

SI. TOPZ  =  S.TOPZ-1; 

Sl.Z(J)  =  S.Z(J); 

END . S 1 . Z ( J )  =  ( J=S1 .TOPZ) ; 

END; 

MODI  IIN  TOP ( S  : STACK )  M  UIIINS  (X  :  INTEGER) ; 

X=S . Z (S . TOPZ ) ; 

END; 

MODI  UN  EMPTYSTACK  Rl  TURNS  (SI : STACK) ; 

SI . TOPZ  =  0 ; 

END ; 

I  ND  STACK; 


In  the  above  example,  representation  for  a  stack  consists  ol  two  components:  a  100 
element  integer  array  caller)  Z.  and  an  integer  TOPZ.  The  familiar  notation  of  record  (as  in 
PL/I,  Pascal  etc  )  is  used  to  show  the  components  of  stack  Variables  SI  and  S  which  occur 
in  the  modfuns  are  of  data  type  stack.  Outside  the  STACK  module  the  two  components  of 
stack  are  not  visible,  however  inside  tfie  module  the  variables  S  and  Si  are  seen  to  consist  of 
two  components  To  refer  to  their  components  qualified  names  are  used.  e  g.  Si  TOPZ  refers 
to  a  component  of  stack  S' ,  while  S  TOPZ  refers  to  that  of  stack  S. 


The  STACK  module  can  tie  analysed  for  consistency  independent  of  the  use  of  stack  data 
type.  The  modfuns  PUSH  and  POP  define  a  stack  by  defining  the  value  of  its  components 
which  satisfy  certain  relationship  with  components  of  another  stack  For  example,  the 


modfun  PUSH  defines  the  value  of  a  stack  Si  in  terms  of  stack  S  and  integer  X.  which  are  the 
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formal  parameters  of  PUSH  The  two  components.  Z  and  TOPZ,  of  the  stack  Si  are  defined  in 
terms  of  the  components  of  the  stack  S  and  integer  X.  EMPTYSTACK  defines  a  stack  which 
satisfies  certain  properties  independent  of  any  other  stack;  TOP  defines  an  integer  with 
respect  to  the  stack  S,  which  is  a  again  a  formal  parameter. 

The  definition  of  the  array  of  stacks,  A.  in  the  main  module  does  not  require  knowledge  of 
the  representation  of  stack.  It  can  he  analysed  for  consistency  independent  of  the  module 
STACK. 

3.7  RECURSIVE  DEFINITIONS 

Modules  can  be  used  to  define  data  types  whose  representation  is  specified  recursively. 
For  an  abstract  data  type,  say  A DT.  its  representation  can  be  specified  in  terms  of  variables 
which  themselves  can  be  of  type  ADT.  Modfuns  can  now  tie  applied  to  these  variables 
recursively  to  define  their  values. 

The  recursive  data  types  are  illustrated  below  by  means  of  an  example.  Stack  of  stacks 
data  types  (SOS  for  short)  is  chosen  to  show  the  similarity  with  the  previous  stack  example. 
The  specification  of  SOS  is  same  as  that  for  STACK  except  that  the  data  type  of  the  array  Z  in 
the  representation  of  SOS  is  of  type  SOS  instead  of  INTEGER. 
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MAIN  EX2; 

DCL  S.T:  SOS  ARRAY(IOO); 

S( I )  =  IF  1=1  THEN  PUSHS( EMPTYSOS ,  EMPTYSOS) 
ELSE  PUSHS(S(I-1) ,  EMPTYSOS); 
T(I)  =  IF  1=1  THEN  PUSHS( EMPTYSOS,  S(l)), 
ELSE  PUSHS(T(I-1).S(I)); 

END  EX2; 


U 

U 

u 


-  -  S(3) 

-  -  S(2) 

--  S(1) 


T(1)  T (2)  T(3) 


LI  =  stack  symbol 
El  =  stack  containing 


Figure  3- 1 ;  EXAMPLE  EX2:  USING  STACK  OF  STACKS 
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MODULE  SOS; 

DCL  1  SOS:  RECORD, 

2  TOPZ :  INTEGER, 

2  Z:  SOS  ARRAY(IOO); 

J  IS  A  SUBSCRIPT; 

MODE  UN  PUSHS(3 : SOS , X : SOS)  RE  TURNS  (SI: SOS); 
SI. TOPZ  =  S . TOPZ  +  1; 

Sl.Z(J)  =  IF  (J  <=  S .TOPZ)  THEN  S.Z(J) 

ELSE  X; 

END.Sl.Z(J)  =  (J  =  SI. TOPZ); 

END ; 

MODFUN  POPS(S:SOS)  RETURNS  (SI :  SOS) ; 

SI. TOPZ  =  S .TOP  -  1; 

Sl.Z(J)  =  S.Z(J); 

END.Sl.Z(J)  =  (J  =  SI. TOPZ); 

END ; 

MODFUN  TOPS(S:SOS)  RETURNS  ( X  :  SOS ) ; 

X  =  S.Z(S.TOPZ); 

END-, 

MODFUN  EMPTYSOS  RETURNS  (Sl:SOS); 

SI. TOPZ  =0; 

END; 

END  SOS; 


Stack  of  stacks  (SOS),  as  defined  above,  is  not  very  useful  because  it  cannot  handle  a 
stack  of  integers.  A  SOS  can  only  contain  other  SOS’s.  The  difficulty  arises  because  the  data 
type  of  Z,  a  component  of  SOS,  is  restricted  to  be  of  data  type  SOS;  hence  it  does  not  allow  a 
stack  of  integers  to  be  part  of  SOS.  There  are  a  number  of  ways  of  dealing  with  the  problem, 
e  g.  parameterized  modules,  disjoint  union  of  data  types  etc.  explained  below.  A  particularly 
elegant  method  is  by  using  parameterized  modules. 

A  generic  or  parameterized  module  defines  a  class  of  data  types.  Different  values  of  the 
parameter  of  the  module  result  in  different  members  of  the  class  of  data  types  The  SOS 
example  is  rewritten  using  generic  module.  A  single  module  defines  stack  of  integers,  stack 
of  characters,  stack  of  stacks  etc.  depending  on  the  value  of  the  parameter. 


STK  specifies  a  parameterized  stack.  Its  parameter  is  a  data  type  which  determines  the 
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components  which  a  given  STK  can  have.  For  example,  S  is  declared  to  be  an  array  of  stacks 
of  integers  i.e.  each  of  the  element  of  the  array  S  is  a  stack  and  can  contain  integers. 
Similarly,  T  is  an  array  of  stack  of  stacks.  At  the  time  of  declaration  of  variables  of  data  type 

STK,  the  parameter  of  STK  must  be  specified. 

MAIN  EX3  ; 

DCL  S:  STK[INTEGER]  ARRAY ( 100) , 

T:  STK[STK]  ARRAY(IOO); 

S(I)  =  PUSHSTK(EMPTYSTK( INTEGER) ,  I); 

T ( I )  =  IF  1=1  THEN  PUSHSTK( EMPTYSTK(STK) ,  S(l)), 

ELSE  PUSHSTK(T(I-1) ,S(I)) ; 

END  EX3 ; 


T(1)  T(2)  T(3) 


Figure  3-2:  EXAMPLE  EX3:  USING  PARAMETERIZED  STACK 


Figure  3  2  illustrates  the  various  stacks  in  EX3,  by  means  of  a  picture. 
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MODULE  STK[U :  TYPE]; 

DCL  1  STK :  RECORD, 

2  TOPZ :  INTEGER, 

2  Z:  U  ARRAY(IOQ); 

J  IS  A  SUBSCRIPT; 

MODEUN  PUSHSTK(S:STK[V],  X:V)  RETURNS  (S1:STK[V]); 
SI. TOPZ  =  S . TOPZ  +  1; 

Sl.Z(J)  =  IF  (J  <=  S .TOPZ)  THEN  S.Z(J) 

ELSE  X; 

END.Sl.Z(J)  =  (J  =  SI. TOPZ); 

END; 

MODIUN  POPSTK(S  :  STK  [  V]  )  RETURNS  (S1:STK[V]); 

SI. TOPZ  =  S.TOP  -  1; 

Sl.Z(J)  =  S.Z(J); 

END.Sl.Z(O)  =  (J  =  SI. TOPZ); 

END ; 

MODEUN  TOPSTK(  S  :  STK[V]  )  RETURNS  (X:V), 

X  =  S.Z(S.TOPZ); 

END; 

MODEUN  EMPTYSTK(  V:  TYPE  )  RETURNS  (S1:STK[V]); 

SI. TOPZ  =  0; 

END; 

END  STK; 


The  construct  of  disjoint  union  also  allows  a  single  module  to  define  a  class  of  data  types. 
A  variable  is  said  to  be  of  disjoint  union  of  data  types  X  and  Y,  if  Ihe  vaiiable  can  take  a  value 
denoted  by  either  of  the  data  types,  and  there  is  a  way  to  distinguish  whether  its  value  is  of 
data  type  X  or  data  type  Y.  Part  of  SOS  example  is  rewritten  below  to  illustrate  the  idea  In  the 
example,  a  tag  field  is  associated  with  the  SOS  record,  which  indicates  one  of  two  possible 
choices  in  the  variant  part  of  the  record.  Thus  depending  on  the  tag  field,  it  represents  a 
stack  of  integers  or  stack  of  stacks  (It  is  assumed  that  TYPE  OF  STACK  is  a  data  type 
defined  to  be  a  set  consisting  of  two  keywords  INTEGER  and  SOS  CASE  has  similar  meaning 
as  in  Pascal.)  Accordingly,  ttie  data  type  of  the  parameter  X  in  the  function  PUSIISTK  is  of 


type  SOS  or  INTEGER. 
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MODULE  STK ; 

DCl  1  STK;  RECORD, 

CASE  TAG;  TVPE-OF-STACK  OF 
INT:  2  TOPZI :  INTEGER. 

2  ZI:  INTEGER  ARRAY ( 100) , 

SOS:  2  TOPZS :  INTEGER. 

2  ZS:  STK  ARRAY(IOO); 

J  IS  A  SUBSCRIPT; 

MODFUN  PUSHSTK(S:STK,  X ;  CASE  ( STK  .  INTEGER  ) )  ILL  I  UHNS(S  1 :  STK) ; 
CASE  S. TAG  OF 

INT:  SI. TOPZI  =  S. TOPZI  +  1; 

Sl.ZI(J)  =  IF  (J  <=  S. TOPZI)  THEN  S.ZI(J) 

ELSE  X; 

END.Sl.ZI(J)  =  ( J  =  SI. TOPZI); 

SOS:  SI. TOPZS  =  S. TOPZS  +  1; 

Sl.ZS(J)  =  IF  (J  <=  S. TOPZS)  THEN  S.ZS(J) 

ELSE  X; 

END . S 1 . ZS ( J)  =  (J  =  SI. TOPZS); 

END ; 


END  STK; 

Unlike  the  parameterized  module,  the  class  of  stacks  that  STK  specifies  is  limited  to  those 
explicitly  defined  in  the  module,  e  g.  in  the  above  example  it  is  limited  to  two  INTEGER  and 
STK.  In  case  of  the  parameterized  module,  the  class  of  stacks  specified  by  STK  is  left  open  m 
the  specification. 

Disjoint  union  and  parameterization  ore  not  included  while  defining  the  semantics  of 
modules  to  keep  the  treatment  simple.  Parameterized  modules  (or  disjoint  union)  can  always 
be  replaced  by  a  number  of  different  modules,  each  corresponding  to  a  different  value  of  the 


parameter  (or  a  different  data  type  in  the  union). 


I 

I 
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3.8  SEMANTICSOF  MODULES 

This  section  defines  the  denotationa!  semantics  or  the  fix  point  semantics  of  the  modules. 
The  denotational  approach  has  been  chosen  because  the  semantics  so  defined  is 
independent  of  the  computation  rules  (or  the  interpreter)  used  to  evaluate  the  modules.  This 
may  be  contrasted  with  the  operational  or  axiomatic  approach,  in  which  the  semantics  is 
defined  in  terms  of  the  interpreter.  The  denotational  approach  is  particularly  suited  for 
non  procedural  languages,  because  these  languages  are  independent  of  the  sequence  of 
control  of  the  statements.  The  denotational  semantics  of  modules  shows  two  things:  (1)  the 
module  defines  a  set  of  functions,  and  (2)  the  functions  can  be  computed. 

The  equations  and  arrays  in  the  specification  are  considered  as  partially  defined  recursive 
functions.  This  allows  us  to  translate  our  notation  into  the  standard  recursive  function 
equations,  and  use  the  results  regarding  least  fix  point  already  known  in  that  domain. 

Some  of  the  important  definitions  used  in  denotational  semantics  are  described  here. 
Partial  ordering  on  every  extended  domain  D+  =  D  U  )1),  where  1  stands  for  the 
undefined  value,  corresponds  to  the  notion  of  less  defined  than  ot  equal  to.  It  is  defined  as: 

±  <d.  and  d  r<d  Vd  e  D  + 

A  function  f  is  said  to  be  monotonic  if: 
x -<  y  f(x)Xf(y)Vx,yeD  + 

Starting  with  these  basic  definitions  semantics  for  recursive  equations  is  defined  (Chap.  5  in 

[37]). 

First,  the  semantics  of  equational  specification  (Section  3.2)  is  presented.  It  is  based  on 


[40],  Later,  it  is  extended  to  give  semantics  to  modules.  It  is  also  shown  that  a  module 
specification  defines  a  set  of  algebraic  axioms  satisfied  by  the  abstract  data  type. 
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An  equational  specification,  introduced  informally  in  Section  3  2.  for  the  array  symbols  A,, 
...  An  of  dimensionalities  d,,  ...  dn.  and  data  types  Tt.  ...  T„  respectively,  is  a  system  of 
equations: 

A, (I,.  *<j  1 )  =  ri(*i  ■■■  Idj’Av  An) 

A„d,.  Idn)  =  in(l,  l[jn> A , ,  ...  An) 

The  terms  rt(l,, ...  Id  .A,,  ...  An)  for  i  =  1  to  n  aredefined  recursively  as  follows: 

Letters  f ,,f2 _ are  used  to  denote  functions  over  array  values:  and  y,.y2....  are  used  to 

denote  inteyer  valued  functions  used  as  subscripts  A  subscript  is  defined  as  follows: 

1  lk  is  a  subscript  Its  appearance  in  r,  satisfies  k  <  dr 

2.  lk-c  is  a  subscript,  where  c  is  an  interpreted  inteyer  constant. 

3  If  J , ,  ...  J„  are  subscripts,  then  so  is  y,(Jt.  ...  Jn). 

A  term  is  defined  as: 

I  If  Jt.  ...  Jn  are  subscripts,  then  A,(J ...  JJ  is  a  term  of  data  type  T,. 

2.  If  t , ,  ...  tm  are  terms  of  data  types  S,,.  ...  S,n,  respectively,  then  f,(t,.  ...  t(„)  is  a  term 
of  data  type  S,  (where  occurrence  of  the  symbol  t,  is  always  followed  by  terms  of 
the  data  types  S, , ,  ...  S(m). 

An  interpretation  for  a  specification  consists  of 

1 .  domains  D,. ...  D,  over  which  the  elements  of  array  vary,  and  let  D  =  { D , ,  ...  Dr}; 

2,  a  one-to-one  onto  mapping  M  such  that:  M(x)  =  D,.  where  x  is  a  data  type,  and  D, 
tO; 

3  an  assiynment  of  concrete  functions  to  the  symbols  { f, } .  i.e.  Iff,]:  *  X  +  X  ... 

D,  1  ->  D(  ‘  where  m  is  the  arity  of  f,.  S,  the  data  type  for  the  j,h  argument  of  the 
function  satisfies  the  relation  M(S, )  =  D, ,  and  similarly  the  data  type  for  the  range 
of  the  function  satisfies  M(S,)  =  Dr  where  D,  r  D  for  1  <  j  <  m,  D,  r  D;  and 
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4.  an  assignment  of  concrete  natural  number  functions  to  the  symbols  {g,}  i.e  l[g,]: 

(Z  +  )d'  -*  Z  * ,  where  d,  is  the  arity  of  gj. 

where  D, f  is  the  extended  domain,  D|  *  =  D,  U  { _L } ;  and  Z*  is  the  extended  domain  of 

natural  numbers.  Z +  =  Z  U  {!},  where  _L  stands  for  undefined  value  Moreover  f,  and  g,  are 

\ 

restricted  to  be  monotonic  in  the  sense  of  partial  ordering. 

Least  fix  point  semantics  is  adopted  to  give  a  meaning  to  the  specification.  Thus,  the 
solution  to  a  given  set  of  equations  is  taken  to  be  the  least  fix  point  solution.  Each  of  the  A,  is 
specified  as  a  partial  function,  A,:  Z'1'  — *  D,  Monotonicity  of  functions  f , ,  f2.  ...  g,.  g2,  ••• 
assures  that  the  r,  are  continuous.  Therefore,  the  least  fix  point  solution  exists  and  is  unique 
(Thms.  5-1,5  2  in  [37]). 

The  semantics  of  module  specification  is  presented  next.  A  module  specification  consists 
of  the  declaration  of  the  representation  for  the  abstract  data  type  specified  by  the  module,  and 
the  operations  which  may  be  performed  on  variables  of  the  type  Let  an  abstract  data  type 
called  ADT  be  specified  by  a  module  of  the  same  name.  The  modfuns  specified  by  the  module 
may  be  divided  into  two  classes: 

1 .  those  which  return  a  variable  of  data  type  ADT,  and 

2.  those  which  return  a  variable  of  data  type  other  than  ADT. 

Semantics  of  modfuns  for  each  of  the  classes  will  be  presented. 

Representation  of  the  abstract  data  type  ADT,  in  its  most  general  form,  is  given  by  a 

structure  of  the  form: 

del  1  ADT:  record, 

2A,:T,, 

2  V  Tm 


Li 
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where  A/s  are  the  variables  and  T,’s  are  then  data  types  respectively.  Each  of  the  A/s  may  be 
arrays  or  simple  variables.  A  structure  declaration  is  yiven  the  semantics  o(  a  tuple,  and 
therefore,  the  structure  for  ADT  denotes  the  tuple: 

<A,,A2, ...  An>. 

Note  that  since  any  of  the  T/s  may  in  turn  be  of  type  ADT.  the  abstract  data  type.  ADT.  may  be 
defined  recursively. 

A  modfun  in  the  module  ADT  which  returns  a  variable  of  data  type  ADT  is  of  the  form: 

MODFUN  OPC(C,:ADT,  ...  Cp:ADT.B,:u,.  ...  Bq:u(|)  RL  ruf?A/S(C:ADT); 

C.A,(lt,...ldi)  =  r  ,(l,,  ...  Id t , A , ,  ...  An,C.B.op) 

C  An(l,,  ...  Idn)  =  Tn(l,.  ...  lvA,,  ...An,C,B.QE) 

END 

where  OPC  is  the  name  of  the  modfun;  C/s  are  the  formal  parameters  of  data  type  ADT.  B/s 
are  formal  parameters  of  data  types  u/s  respectively  where  none  of  the  u/s  is  ADT;  and  T;’s 
represent  expressions.  C  is  used  to  denote  C,.C2.  Cp:  B  to  denote  B,.  B2.  Bg;  and  op  to 
denote  the  modfuns  in  the  module  A/s  are  array  symbols  and  are  components  of  the  tuple  of 
ADT,  defined  earlier  The  d/s  give  the  arities  of  the  corresponding  A/s,  and  I/s  are  the 
subscripts  of  the  respective  A/s,  where  1  <  j  <  d,. 

The  expressions  r/s  can  now  be  defined  as  below  Letters  f,.f2.  are  used  to  denote 
functions  over  array  values;  and  y,,g2,  are  used  to  denote  integer  valued  functions  used  as 
subscripts.  A  subscript  is  defined  as  follows: 

1  I,,  is  a  subscript  Its  appearance  in  t,  satisfies  k  <  d,. 

2  I ,  c  is  a  subscript,  where  c  is  an  interpreted  integer  constant. 

I 


3.  If  J,.  J„  are  subscripts,  so  is  g,(J,.  Jn). 
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A  term  is  defined  as: 

1.  If  J,.  ...  Jd  are  subscripts,  then  Cj.A|(J,,  ...  Jd )  is  a  term  of  data  type  Tt;  where  j 
satisfies  1  <  j  <  p,  and  i  satisfies  1  <  i  <  n. 

2.  Bj(l1 .  ...  Id  )  is  a  term  of  data  type  u(,  where  1  <  i  <  q. 

3.  If  t,. ...  tni  are  terms  of  data  types  Sjt. ...  Sjm  respectively,  then  f,(t, ,  ...  tm)  is  a  term 
of  data  type  S,,  where  occurrance  of  f,  is  always  followed  by  terms  of  data  types 

Si,.  •••  sjm. 

4.  Same  as  (3)  with  the  symbol  f  replaced  by  op,  where  op  t  op,  and  S^'s  replaced 
appropriately. 

The  following  interpretation  is  given  to  the  above  set  of  equations. 

1.  a  set  of  basic  domains  D, ,  ...  Dt  including  domain  Z  of  the  set  of  positive  integers, 
andletDtol  =  {D,, ...  Dr,  D},  where  set  D  is  defined  by  the  module; 

2.  for  each  of  the  data  types  Tj's,  u/s  and  ADT  define  a  one-to-one  onto  mapping  M 
such  that: 

M(ADT)  =  D 

M(x)  =  d  where  x  e  {T,  ...  Tn,u,  ...  uq} 
and  d  c  {Dt0,  -  0} 

3.  for  each  symbol  f,  of  arity  d;  assign  a  concrete  function: 

V  Dj,  X  ...X  Dld.  — *  Dj 
where  D,  e  D(0( 
and  Vk,  Djk  e  D,ot 

where  S^,  the  data  type  for  the  j,h  argument  of  the  function  I,  satisfies  M(Sj()  =  D^, 
and  Sjt  the  data  type  for  the  range  of  the  function  satisfies  M(S,)  =  D,: 

4.  for  each  symbol  g,  of  arity  d,  assign  a  concrete  number  theoretic  function: 

9j:  (Z +  )d’  — ►  Z + ; 

5.  a  set  of  projection  functions  P,’s  such  that 

<Aj, ...  An>.A|  =  P,(<At, ...  An>) 
and  with  subscripts  and  symbol  Cj  for  the  tuple 
C,  At(l,,...ld.)  =  P,(C))(l„...ldj) 


I 

I 
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for  1  <  j  <  p 
and  1  <  i  <  n; 

6.  a  set  of  functions  OPC,,  ...  OPCn  (instead  of  the  multi  valued  function  OPC) 
defined  as  follows: 

OPC,(C,B,l„  ld))  =  C.A(l,,...ld]) 

OPCn(C.B.I,,  ...ldn)  =  C.A(I,..  ..Idn); 
wftere  C  and  B  are  the  formal  oarameters  of  OPC. 

With  the  interpretations  (5)  and  (6)  the  equational  specification  of  a  module  can  be  written 
in  the  familiar  form  of  recursive  equations: 

OPC1(C,B.I1,...ld))  =  T1(l,....l,)|.E,C.B,ofi) 

OPCn(C,g,l„...ldn)  =  rn(l,....ldn.P.C.B,oc) 

where  op  is  the  set  of  operations  with  proper  substitutions.  (For  example  OPC  i  op  is  written 
as  the  tuple  <OPC,.  ...  OPC„> .)  P  represents  P,. ...  Pn. 

For  each  of  the  modfuns  of  class  1,  i  e.  those  which  return  a  value  of  data  type  ADT,  a 
similar  set  of  recursive  equations  can  be  written. 

For  each  of  the  modfuns  of  class  2.  i  e  those  which  return  a  value  of  data  type  other  than 
ADT,  a  similar  but  simpler  set  of  recursive  equations  can  be  written  A  modfun  belonging  to 
the  second  class  is  of  the  form: 

MODI  UN  OPD(C,:ADT.  ...  Cp:ADT.B,:u,.  ...  Bq:uq)  nETUnNS{E:u) 

Ed,,  'd,)  =  Od,.  ldl.A,....An,C.B,sfi) 

END 


which  reduces  to  the  recursive  equation: 
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OPD(Q,B.I1....ld)  =  T(l1....ld,P,C.B,Qfi) 

All  the  recursive  equations  are  now  put  together,  by  renaming  the  variables  which  occur  as 
formal  parameters  of  modfuns,  to  avoid  clash  of  names. 


The  functions  f,,f2 . g,,g2,  are  constrained  to  be  monotonic  in  the  sense  of  partial 

ordering.  The  projection  functions  are  monotonic  because: 

Let  P,  be  the  ilh  projection  function.  Now 
let  x  =  <x,, ...  xr  ...  xn> 
and  y  =  <y,. ...  y,, ...  yn> 

x  ■<  y  =>  x,  K  y,  for  all  i.  (where  "y<"  stands  for  less  defined  than  or  equal  to) 

P|(X)  =  X; 

Pj(y)  =  y, 

X  ^  y  =>  P,(X)  ■<  P,(y) 
therefore,  P,  is  inonotonic. 

Hence,  t,’s  are  continuous  and  the  least  fix  point  solution  of  the  recursive  equations  exists 
(Thms.  5  1,5  2  in  [37]). 

The  set  D,  which  corresponds  to  the  data  type  ADT,  is  defined  inductively  as  follows: 

1.  Base  step  For  a  modfun  OP  which  returns  a  value  of  data  type  ADT.  and  none  of 
whose  formal  parameters  is  of  type  ADT.  the  tuple  defined  by  OP:  <OP,,  ... 
OPn>(B)  is  a  member  of  set  D.  B  are  the  formal  parameters  of  function  OP,  and 
OP  represents  a  tuple  of  functions. 

2.  Inductive  step  For  a  modfun  OPC  which  returns  a  value  of  data  type  ADT,  the 
tuple  defined  by  the  modfun:  <OPC,. ...  OPCn>(C,B)  is  a  member  of  set  D;  where  C 
are  the  members  of  set  D,  and  B  are  members  of  other  domains  (D(ot  D). 

The  existence  of  the  least  fix  point  solution  assures  the  existence  of  the  set  D. 

With  the  semantics  of  the  modules  defined,  algebraic  axioms  about  the  abstract  data  types 
can  now  be  proved.  The  proof  involves  substituting  non  procedural  equations  for  the 
occurrances  of  the  module  functions,  and  reducing  the  equations  until  the  desired  equality  is 


obtained.  This  is  illustrated  by  means  of  the  STACK  example.  Note  that  since  it  does  not 


s 
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involve  recursive  definition  of  the  data  type  tfie  derivation  is  straight  forward. 


To  prove.  POP(PUSH(S.X))  =  S.  where  S  is  a  stack,  and  X  is  an  integer. 


Proof: 

LHS 

=  POP(S')  where  S'  is  a  stack  and 
S  .TOPZ  =  S.TOPZ  +  1 

S.Z(J)  if  J  <  S.TOPZ 
S'.Z(J)  =  X  if  J  =  S  .TOPZ 
±  otherwise 


=  S"  where  S"  is  a  stack  and 
S-.TOPZ  =S  .TOPZ  •  1 

S".Z(J)  =  S’.Z(J)  if  J  <  S  .TOPZ 
1  otherwise 


=  S"  where  S"  TOPZ  =  S.TOPZ 

S "  Z(J)  =  S.Z(J)  if  J  <  S.TOPZ 
_L  otherwise 


=  S"  where  S"  TOPZ  =  S.TOPZ 

S"  Z( J)  =  S.Z(J)  VJ  (from  Lemma  1 .) 


=  S 


O  E  D. 


l  emma  I:  VS  c  STACK.  S,Z(J)  =  J.  for  J  >  S.TOPZ 


Proof:  Since  the  stacks  can  only  be  defined  by  the  modfuns  in  the  module  STACK,  the 
proof  follows  from  induction: 

Base  step  Follows  from  the  definition  of  the  FMPTYSTACK. 
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Induction  step:  Let  S  be  a  stack  satisfying  the  proposition  of  the  Lemma. 

Claim:  The  stacks  POP{S,X)  and  PUSH(S.X)  also  satisfy  the  lemma. 

Proof: 

1. 

LetS'  =  POP(S,X) 

S  .Z(J)  =  X  for  J  >  (S.TOPZ  •  1) 

=  X  for  j  >  S  .TOPZ 

2. 

LetS'  =  PUSH(S,X) 

S'.Z(J)  =  X  for  J  >  S’.TOPZ 

Q.E.D. 

3.9  SUMMARY 

This  chapter  introduces  a  non  procedural  language  based  on  equations.  Use  of  abstract 
data  types  has  been  proposed  as  a  means  to  introduce  modularity  in  the  non  procedural 
language  It  has  been  argued  that  the  use  of  abstract  data  types  is  consistent  with  the 
philosophy  of  non  proceduralness,  and  leads  to  modular  specifications. 

The  notion  of  "module"  has  been  introduced  to  allow  specification  of  the  abstract  data 
types.  It  allows  the  definition  of  the  representation  of  the  abstract  (fata  types,  and  the 
specification  of  the  functions  which  can  operate  on  it.  These  functions  are  specified 
non  procedurally  by  means  of  equations. 

Finally,  the  denolational  semantics  of  the  modules  is  defined  It  is  shown  that  an  abstract 
data  type  defined  by  a  module  is  a  well  defined  set.  it  is  also  illustrated  that  the  axioms 


satisfied  by  the  abstract  data  types  can  be  derived  from  the  equational  specification. 


Chapter  Four 


THE  NOPAL  LANGUAGE 

4.1  OVERVIEWOF  THE  NOPAL  LANGUAGE 

Nopal  is  a  descriptive  language  used  to  write  specifications  for  the  programming  of 
automotic  test  systems.  It  can  be  used  for  testing  of  electronic  circuits,  mechanical  systems, 
chemical  processes  etc.  It  also  has  the  capablity  to  perform  general  purpose  computational 
tasks. 

Basic  statements  in  Nopal  are  assertions  and  data  declarations  similar  to  those  described 
in  Chapter  3.  However,  Nopal  has  additional  constructs  which  are  superimposed  on  the 
assertions  and  data  declarations.  These  additional  features  facilitate  the  specification  of 
testing.  The  most  important  construct  is  that  of  a  test.  A  test  section  consists  of  a 
specification  of  a  physical  test.  Outcome  of  the  test,  i.e.  passing  or  failing  the  test,  determines 
fault  isolation.  There  are  also  sections  to  describe  the  UUT  (Unit  Under  Test)  and  the  ATE 
(Automatic  Test  Equipment).  These  sections  are  needed  to  check  consistency  of  interfaces 
with  the  UUT  and  ATE. 

Several  features  of  Nopal  are  extremly  important  in  providing  ease  of  use.  First,  the 

language  is  non  procedural.  The  user  saves  effort  because  the  execution  order  of  events  or 

control  logic  need  not  be  specified.  Second,  the  specification  can  be  divided  into  sub  parts, 

the  modules  Each  of  the  modules  can  be  specified  and  processed  by  the  language  processor 

independently.  This  is  the  essence  of  modularity  of  a  specification  Third,  each  of  the 

modules  may  be  further  divided  into  d.itj  deci.iuhon:.  and  functions  The  functions  are 

4  1 
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divided  into  tests,  diagnoses  and  messages.  Each  test  has  sub  parts:  stimulus,  measurement 
and  logic  All  these  correspond  to  notions  which  occur  in  testing  Fourth,  the  language 
allows  incremental  development  of  specification  Tests  can  be  added  to  a  specification 
without  changing  the  tests  already  specified. 

The  Nopal  system  produces  a  number  of  leports  which  serve  as  the  documentation  for  the 
specification.  It  also  enhances  the  user  system  interaction,  and  helps  the  user  in  locating 
errors  in  the  specification. 

In  this  chapter,  the  Nopal  language  is  described  informally  with  examples  A  more  detailed 
explanation  including  the  formal  syntax  is  given  in  [46], 

A  Nopal  specification  gives  a  complete  description  of  the  desired  tests  specific  to  a  given 
UUT  and  ATE  In  general,  a  Nopal  specification  consists  of  a  collection  of  modules.  One  of  the 
modules  is  called  the  w  module  and  it  consists  of  the  tests  on  a  given  UUT  with  an  ATE. 
Communication  between  tire  modules  is  by  means  of  abstract  data  types  A  module  (except 
the  main  module)  represents  an  abstract  data  type  which  can  be  used  by  other  modules. 

A  module  specification  includes  the  data  representation  lor  an  abstract  data  type  together 
with  the  functions  (called  module  functions  or  modfuns  for  short)  which  can  operate  on  the 
variables  of  the  abstract  type  (also  called  <ibstiact  vu/tablcs  for  short)  An  abstract  data  type 
that  has  been  specified  by  means  of  a  module  can  be  used  in  any  of  the  modules.  The 
abstract  variables  are  defined  and  operated  upon  by  means  ol  the  modfuns  specifier!  in  the 
module. 

The  modules  are  specified  non  proceduially.  For  organizational  purposes  each  module 
can  be  divided  into  four  major  sections,  which  can  be  given  in  any  order.  They  are: 


t.  Data  declaration  specification. 
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2.  Modfun  specification. 

3  UUT  specification,  and 

4  ATE  specification. 

Each  of  the  four  sections  are  •  xplained  briefly  below,  followed  by  a  more  detailed  description 
later. 

The  data  declaration  specification  provides  the  data  types  of  the  variables  and  the  data 
structure  used  in  the  specification. 

The  modfun  specification  describes  the  mapping  between  the  input  and  the  output 
parameters  of  the  modfun  The  main  module  has  only  one  (implicit)  modfun.  while  the  other 
modules  may  have  more  than  one.  Each  modfun  consists  of  tests.  diagnoses  and  messages. 
The  tests  may  be  further  sub  divided  into  stimuli,  measurements  unci  logic.  A  test 
corresponds  to  the  notion  of  a  physical  test  on  the  UUT.  i.e  application  of  stimuli,  taking  of 
measurements  and  selection  of  diagnoses,  based  on  the  results  of  the  test  as  expressed  in  the 
logic  part  The  diagnoses  report  of  the  test  consists  ol  messages  that  typically  identify  the 
faults  in  the  UUT. 

The  UUT  specification  gives  the  description  of  failure  modes,  connection  points  etc.  of  the 
UUT.  This  description  is  cross  checked  by  the  language  proc.essoi  for  consistency  within  the 
module. 

The  ATE  specification  provides  the  description  of  the  functions  used  in  the  module.  These 
functions  can  be  used  for  application  of  stimuli,  taking  of  measurements,  or  for  computations. 
These  functions  must  be  specified  outside  the  module.  Ttiey  can  be  either  part  of  a  library  of 
functions,  or  they  can  be  specified  as  modfuns  by  other  modules.  The  ATE  specification  gives 
the  function  parameters  and  their  data  types  In  other  words,  it  gives  the  specification  of  the 
interface  with  the  rest  of  the  modules  and  witfi  ATE. 
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4.2  DATA  DECLARATION  SPECIFICATION 

The  data  declaration  specification  allows  the  user  to  declare  the  data  types  of  variables. 
The  data  type  of  a  variable  specifies  the  set  to  which  (the  value  of)  the  variable  must  belong, 
and  the  operations  which  can  be  performed  on  it . 

Data  types  can  tie  either  elementary,  eg  real,  integer,  or  character  or  they  can  be 
abstract,  in  which  case  they  must  be  specified  by  means  of  modules. 

Data  declarations  include  specification  of  the  structure  of  the  data.  The  two  basic 
structuring  methods  are:  (1)  arrays,  and  (?)  structures  An  auay  is  a  homogeneous  structure 
of  elements,  all  of  which  are  of  the  same  data  type  A  structure,  on  the  other  hand  may  consist 
of  components  of  different  types  which  aie  grouped  togethoi  The  components  themselves 
can  be  arrays  or  structures,  thus  permitting  structures  ot  arbitrary  complexity  to  be  declared 

A  structure  may  tie  viewed  as  a  tree  The  root  of  a  tree  represents  the  entire  structure,  and 
its  descendents  couespond  to  tire  components  of  the  strut. lure  I  mally.  the  leaves  of  the  tree 
correspond  to  the  individual  variables  in  the  structure  Below  are  some  examples  of 
declarations  of  variables: 


OCL 

A.B.X 

INTEGER; 

DCL 

Y ,  Z 

STACK  ARRAY 

(10) 

DCL 

1  P 

GROUP  ARRAY 

(5). 

2  Q  :  GROUP  ARRAY  (*). 

3  R  :  INTEGER. 

3  S  :  REAL; 

In  the  first  statement,  variables  A,  R  and  X  are  declared  tn  he  of  type  integer;  In  the  second.  Y 
and  Z  are  declared  to  be  one  dimensional  arrays  of  size  10.  and  data  type  stack;  and  in  the 
ttrird,  a  three  level  tree  structure  is  declaied.  In  the  tree  strucluie  the  root  is  the  variable  P 
having  the  descendant  O  which  has  variables  R  and  S  P  is  an  array  of  five  elements  and  0  an 


array  of  size  which  is  to  tie  specified  elsewhere. 
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A  declared  structure  is  implied  to  be  on  secondary  storage  if  the  data  type  of  the  root  node 
is  FILE  Name  of  the  root  node,  in  that  case,  gives  the  name  of  a  file  and  the  structure 
declaration  gives  the  structure  of  the  file  In  other  words,  the  declared  structure  represents  a 

file,  and  is  called  a  file  structure.  For  example: 

DCL  1  F:  FILE, 

2  P:  GROUP  ARRAY  (*), 

3  Q:  RECORD  ARRAY  (10), 

4  R:  INTEGER, 

4  S:  REAL, 

3  Ql:  RECORD  ARRAY  (6), 

4  Rl:  CHAR; 

A  file  F  is  declared  to  contain  an  anay  P  of  indefinite  size.  Each  element  of  P  contains  10  Q's 
and  5  Qfs. 

A  file  structure  is  considered  by  the  system  to  he  input  if  all  the  fields  (i.e  leaves)  of  the 
structure  are  not  defined  in  the  specification,  and  output  otherwise  The  non  leal  nodes  of  a 
file  structure  can  tie  of  type  RECORD  or  GROUP  A  non  loaf  node  which  corresponds  to  a 
unit  of  input  output  on  the  secondary  storage  is  declared  as  a  RECORD,  and  GROUP 
otherwise. 

Variables  in  an  input  file  structure  aie  defined  in  the  generated  program  by  means  of  a 
special  function  called  ACCESS.  Calls  on  this  function  aie  generated  at  appropiate  places  in 
the  generated  progiam  for  the  specification  SAVE  function  is  the  exact  dual  of  above  for  an 
output  file  structure  Use  of  ACCESS  and  SAVE  function  is  implicit  and  need  not  be  specified 
by  the  user. 

For  ISAM  files  a  key  is  represented  by  a  variable  name  winch  is  the  name  of  the  record 
prefixed  by  "PER  For  example  art  instance  of  a  record  named  in  an  ISAM  file  can  be 
defined  by  means  of  its  key  "PTR  Z"  The  value  of  the  key  is  passed  as  a  parameter  to  the 


\ 


ACCESS  and  SAVE  function. 
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The  notion  of  file  structure  has  been  generalized  to  abstract  structures  in  NOPAL.  An 
input  or  output  structure  can  be  declared  to  be  of  abstract  type  by  specifying  the  data  type  of 
the  root  node  as  abstract  (instead  of  the  Keywords  RECORD.  GROUP  or  FILE)  An  example  of 

an  abstract  structure  is: 

OCl  1  P:  ATI  ARRAY  (•), 

2  Q:  INTEGER, 

2  R:  REAL; 

in  which  a  structure  P  is  declared  to  be  of  abstract  type  AT  1 

An  abstract  structure  is  considered  input  if  the  value  of  all  its  fields  is  not  defined  in  the 
specification,  and  output  otherwise  Value  of  input  abstract  structures  is  defined  in  the 
generated  program  try  means  of  function  named;  "ACCESS."  suffixed  by  the  name  of  the 
abstract  data  type.  In  the  previous  example,  if  the  structure  P  is  input,  its  value  would  be 
defined  by  ACCESS.AT  1 .  The  ACCESS  function  lor  an  abstract  data  type  must  bo  specified  in 
its  module.  Calls  to  this  function  are  generated  at  appropriate  places  in  the  generated 
program  An  exact  dual  of  the  above  is  the  SAVE  function  for  output  abstract  structures. 

Abstract  structures  allow  convenient  representation  of  those  files  v.'hose  physical 
organization  is  different  from  that  specified  in  the  main  module. 

Parameters  can  be  associated  with  ACCESS  and  SAVE  functions  associated  with  abstract 
structures.  The  use  of  parameters  provides  a  means  of  communication  between  the  main 
module  and  the  module  which  defines  the  abstract  structure.  It  allows  the  use  of  abstract 
structures  to  represent  testing  devices  as  well  r or  example,  a  device  which  measures  ratio  of 
two  voltages  on  two  ports  can  simply  be  declared  as: 
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DCL  1  GD:  GAIN_DEVICE  ARRAY  (•), 

2  GAIN:  REAL; 

The  function  ACCESS.GAIN.DEVICE  in  the  module  GAIN_DEVICE  can  give  the  specification 
for  the  appropriate  measurements.  Thus,  each  value  of  the  variable  GAIN  defined  by  means 
of  the  ACCESS  function  represents  a  different  measurement.  Information  relating  to  the  ports 
and  ranges  can  be  passed  as  parameters. 

The  parameters  are  specified  by  a  syntax  similar  to  that  used  for  specifying  key  for  ISAM 
files.  In  the  example  above,  the  parameters  of  the  abstract  record  GD  are  given  by  means  of 
variables  named  PTRt.GD.  PTR2.GD,  etc. 

4.3  MODFUN SPECIFICATION 

This  section  describes  the  specification  of  the  module  functions  (modfuns).  Each  modfun, 
like  a  mathematical  function,  specifies  a  mapping  from  its  domain  to  the  ranges.  A  modfun 
has  zero  or  more  parameters  Parameters  are  called  source  parameters  if  their  value  is 
defined  outside  the  modfun.  and  are  called  target  parameters  if  they  are  defined  in  the  body  of 
the  modfun  A  modfun  can  return  a  value  by  means  of  its  target  parameters  or  explicitly  as  in 
programming  or  mathematics.  The  data  types  of  the  source  parameters  are  the  domains,  the 
data  types  of  the  target  parameters  and  explicitly  returned  value  are  the  ranges  of  the 
mapping  specified  by  a  modfun. 

The  main  module  has  only  one  implicit  modfun;  the  other  modules  normally  contain  more 
than  one  modfun  A  modfun  has  four  parts; 

1 .  header, 

2.  test  specification, 

3  diagnoses,  and 

4.  messages. 
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The  header  must  be  the  first  statement,  after  which  the  tests,  diagnoses  and  messages  may 
occur  in  any  order. 

4.3.1  HEADER 

Each  modfun  starts  with  a  header  consisting  of  the  keyword  MODFUN  followed  by  the 
name  of  the  modfun.  the  list  of  formal  parameters  and  their  data  types,  and  the  data  type  of 
the  value  explicitly  returned  by  the  modfun  It  also  states  which  of  the  parameters  are  source 
and  which  are  target  In  effect,  the  header  defines  the  interface  with  the  other  modules  which 
use  the  modfun. 

For  example  the  following  header: 

MODFUN  PUSH  (S0:S  STACK,  X:S  INTEGER) 

RETURNS  (SI : STACK) ; 

defines  a  function  called  PUSH  which  has  two  source  parameters  30  and  X  arid  it  returns  a 
value  SI.  explicitly  the  data  type  of  SO  and  Si  are  STACK,  and  the  data  type  of  X  is 
INTEGER.  Consequently.  PUSH  specifies  a  mapping  from  its  domains  of  STACK  and 
INTEGER  to  its  range  STACK. 

4.3.2  TEST  SPECIFICATION 

The  test  specification  consists  of  a  collection  of  tests  As  mentioned  earlier,  tests 
correspond  to  the  idea  of  a  physical  test  on  a  UU1  A  tost  consists  of  three  parts  1)  stimuli 
that  are  to  be  applied  to  the  UUT  at  the  test  time.  ?)  mrasnn-mrnt:.  that  need  to  be  taken  and 
conditions  that  must  be  met,  and  3)  logic  to  select  the  diagnoses  based  on  the  result  of 
passing  or  failing  the  test. 

Stimuli  and  measurements  both  optionally  contain  two  parts,  a  conjunction  and  a  set  of 
assertions  (Generic  word,  wavefoim,  is  used  to  refer  to  either  a  <.  (injunction  or  an  assertion). 
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A  conjunction  in  stimuli  specifies  the  simultaneous  application  of  stimuli  to  the  UUT,  while  in 
the  measurement  it  specifies  the  simultaneous  measurement  to  be  taken  of  the  UUT  All  the 
functions  specified  in  conjunctions  must  be  performed  in  parallel.  For  example,  the  following 

conjunction. 

STIM; 

CONJ :  <J1 , J2>  =  PSUPPLV  (30V)  & 

<J3 , J4>  =  FSOURCE ( 1KHZ ,10V); 

specifies  applying  a  power  supply  of  30  volts  across  the  connecting  pins  J1  and  J2,  and 
applying  a  frequency  source  of  1kHz  and  10  volts  between  pins  J3  and  J4. 

A  conjunction  can  also  be  used  with  an  if-statement.  in  which  case  it  is  called  an 
if  conjunction.  An  if  conjunction  consists  of  a  boolean  condition  followed  by  a  conjunction 
after  "  THEN”  and  a  conjunction  after  "ELSE".  One  of  the  coniunctions  following  the  "THEN" 

or  "ELSE"  part  is  performed  depending  on  the  boolean  condition.  For  example, 

STIM; 

CONJ:  IF  VAR<20  THEN  <J1,J2>  =  PSUPPLY  (30V) 

ELSE  <J3,J4>  =  FSOURCE  (1KHZ.10V); 

If  a  variable  VAR  is  less  than  20  then  the  power  supply  and  otherwise  a  frequency  source  is 
applied. 

Conjunctions  are  used  to  specify  some  actions  stimuli  or  measurements  •  on  the  UUT. 
Assertions,  on  ttie  other  hand  are  used  to  specify  relations  that  must  be  satisfied  by  the 
variables.  An  assertion  specifies  relations  between  variables  It  can  be  used  in  two  roles:  as 
an  explicit  definition  of  variables  or  to  specify  a  condition  on  tiie  variables.  Variables  defined 
in  an  assertion  are  said  to  be  target  variables  of  the  assertion.  All  others  variables  in  the 
assertion  are  called  source  variables  of  the  assertion. 

If  an  assertion  does  not  have  any  target  variable  then  it  specifies  a  relation  which  is  tested 
for  truth  value  An  assertion  evaluates  to  true  if  the  specified  relation  is  satisfied,  otherwise  it 
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evaluates  to  false  Assertions  which  have  taryet  vanahle(s).  art?  always  taken  to  evaluate  to 
true. 

The  syntax  of  assertions  is: 

ASRT :  <EXPRESS ION 1>  <RELATIONAL  OPERATOR)  <EXPRESSI0N2> 

SOURCE:  < L I S T  OF  VARS) 

TARGET:  CLIST  OF  VARS); 

<expression1>  and  <expression2>  are  arithmetic  or  boolean  expressions  Relational  operator) 
is  one  of  (  =  ,<,),<  =  ,)  =  .  =  )  <list  of  vars)  is  a  list  of  variables  with  their  subscript  expressions, 
if  any. 

Taryet  variables  in  an  assertion  must  occur  as  <exptessionl )  or  as  the  taryet  parameters 
of  the  function  in  <expression2>  Moreover,  the  relational  operator  must  be  "  =  Examples  of 
assertions  are: 

ASRT:  A  )  B*SIN(30)  S0URCE:A,B; 

ASRT:  A  =  B*SIN(30)  TARGET : A 

SOURCE : B ; 

The  first  assertion  tests  for  the  inequality  and  evaluates  to  true  or  false:  the  second  assertion, 
on  the  other  hand,  defines  variable  A  and  always  evaluates  to  true. 

In  addition  to  arithmatic  operators,  the  t  operator  is  used  in  an  assertion: 

ASRT:  el  =  e2  +  -  o3 ; 

where  el.  e2,  and  e3  are  expressions.  T fie  assertion  is  an  abbreviation  for  the  foltowmy 
relationship: 

e2  e3  <  =  el  <  =  e2  +  e3 

and  evaluates  to  true  provided  the  above  relations  are  satisfied 

Assertions  may  also  be  used  to  specify  a  relation  that  must  tie  satisfied  try  a  taryet 
parameter  of  a  function  in  a  conjunction  f  or  example,  an  assertion  written  as: 


I 


4.3.2  TEST  SPECIFICATION  51 

CON J :  <J1 , J2>  =  VOLTMETER  (<V1) 

SOURCE: VI; 

specifies  that  the  value  of  the  target  parameter  of  the  function  VOLTMETER  must  be  less  than 
VI. 


If  clause  can  be  used  with  assertions  just  as  in  if  conjunctions  Syntax  of  if  assertion  is: 

ASRT :  IF  <B00LEAN  CONDITION  THEN  <ASSERTION> 

ELSE  <ASSERT I0N> 

SOURCE : <LIST  OF  VARS> 

TARGET : <LIST  OF  VARS>; 

The  keywords  THEN  and  ELSE  may  be  followed  by  another  assertion  which  may  again  have 
an  if  clause.  This  allows  the  if  assertion  to  be  nested  to  indefinite  depth  (In  the  present 
implementation,  the  assertion  following  THEN  cannot  have  an  if  clause  Thus  only  a  right 
recursive  tree  is  permitted.) 

The  if  assertion  is  taken  to  evaluate  to  the  same  boolean  value  as  the  selected  assertion 
following  THEN  and  ELSE.  In  other  words,  if  the  boolean  condition  in  an  il  assertion 
evaluates  to  true  then  the  assertion  is  said  to  evaluate  to  the  same  value  as  the  assertion 
following  the  keyword  THEN,  and  if  the  boolean  condition  evaluates  lo  false,  then  the 
assertion  is  said  to  evaluate  to  the  same  value  as  the  assertion  following  the  keyword  ELSE.  If 
an  if  assertion  (or  if  conjunction)  defines  some  variables  in  its  then  part,  it  must  also  define 
exactly  the  same  variables  in  its  else  part. 

The  concept  of  free  subscript  is  introduced  next  Its  use  allows  entire  arrays  to  be  defined 
by  means  of  one  conjunction  or  assertion  It  also  allows  relations  to  be  specified  between 
arrays.  The  notion  and  use  of  free  subscripts  is  similar  to  that  in  mathematics.  For  example, 


the  assertion  with  free  subscript  I. 
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ASRT  :  IF  1=1  THEN  F(I)  »  1 

ELSE  F ( I )  =  I*F( 1-1) 

TARGET : F( I) 

SOURCE : F ( I - 1 ) ; 

defines  Hie  values  of  F(l)  for  all  values  of  free  subscript  I  In  other  words  it  defines  the  entire 

array  F.  Similarly,  the  assertion  with  free  subscript  I 

ASRT:  A( I )  =  B(I) 

SOURCE:  A( I )  ,B(  I ) ; 

specifies  relation  between  two  array  varialiles  A  and  B  This  assertion  is  taken  to  evaluate  to 
true  if  the  relation  holds  for  all  values  of  the  subscript  I. 

Syntax  for  declaration  of  a  free  subscript  is  similar  to  that  of  an  assertion.  Statement 

containing  the  keywoid  SUBSCRIPT  in  the  following  example: 

ASRT:  I  =  SUBSCRIPT  ('A,B:2’,10)  TARGET:  I; 

is  used  to  declare  a  free  subscript  "I"  for  the  fust  dimension  of  array  variable  A,  and  the 
second  dimension  of  array  variable  B  The  size  of  the  respective  dimensions  of  the  variables  is 
ten.  Even  though  the  declaration  looks  like  an  assertion  it  should  not  be  confused  with  an 
assertion  It  declares  a  subscript  which  lakes  values  from  1  to  10.  The  list  of  variables  and 
their  dimensions,  i.e  "A.B  2",  is  called  paront  list. 

Subscripts  are  a  powerful  way  to  define  arrays.  However,  certain  restrictions  have  been 
placed  on  their  use  so  that  the  specification  may  be  analysed  and  an  efficient  program 
generated  Let  I  be  a  free  subscript  A  subscript  must  be  in  one  of  the  following  forms: 

1  a  subscript  term.  e  g.  I  in  A(l); 

2  an  expression  of  the  form  (I  K),  where  K  is  a  positive  integer;  and 

3  another  variable  or  subscripted  variable  e  g.  B(l)  in  A(B(I)),  X  in  A(X). 

For  variables  which  are  targets  in  a  conjunction  or  in  an  assertion,  only  the  first  of  the  above 


three  forms  is  permitted. 
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In  the  declaration  of  a  subscript  the  upperbound  may  be  omitted,  if  it  is  not  known,  and 

replaced  by . .  For  example,  in  the  assertion: 

I  =  SUBS  ( *  F ' . * )  TARGET : I ; 

upper  bound  of  a  variable  F  is  unknown.  For  such  variables,  the  program  generator  tries  to 
optimize  memory.  In  particular,  the  program  generator  allocates  memory  for  2  elements: 
current  and  the  previous.  Elements  corresponding  to  only  the  current  (i.e.  I)  and  the  previous 
(i.e.  I  I)  value  of  subscript  may  be  referenced. 


The  size  of  an  array  variables  with  subscript  I,  whose  upper  bound  has  been  declared  to  be 
indefinite,  is  specified  by  means  of  a  special  array  called  END  I  Such  special  arrays  are  called 

end  arrays.  The  meaning  of  end  arrays  is  introduced  by  means  of  an  example  below: 

I  =  SUBS  ( ’  F  • .  * )  TARGET:!; 

IF  1=1  THEN  F ( I )  =  1 

ELSE  F ( I )  =  I*(f-1) 

TARGET : F( I ) 

SOURCE : F ( I- 1 ) ; 

IF  1  =  6  THEN  END_I(  I )  =  TRUE 
ELSE  END_I ( I )  =  FALSE 
TARGET : END_I( I ) ; 


First  statement,  in  the  example  above,  is  declaration  lor  a  subscript  I.  It  is  followed  by  an 
assertion  which  defines  an  array  F  in  terms  of  itself  The  second  assertion  defines  an 
end.array  ENDI  whose  first  four  elements  are  false  anti  the  fifth  element  is  true  This  specifies 
that  the  size  of  array  F  is  equal  to  five.  In  other  words,  the  size  of  F  is  specified  to  be  equal  to  N 
such  that  for  index  N  the  value  of  ENDJ  is  true  and  for  all  indices  less  than  N  the  value  of 
ENDJ  is  false. 


More  generally,  if  "I"  is  a  free  subscript  then  ENDJ  is  a  multi  dimensional  array,  its 
dimensionality  being  equal  to  the  maximum  dimension  in  the  parent  list  in  the  declaration  of 
"I".  END  I  defines  the  size  of  those  dimensions  of  the  array  variables  which  are  in  the  parent 
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list.  For  example, 

I  =  SUBS  (’6:1. F* .*)  TARGET:!; 

J  =  SUBS  ( ' G : 2 ' . * )  TARGET : J ; 

the  dimensionality  of  END.I  is  one  and  that  of  END.J  is  two  END.I  defines  the  size  of  the  one 
dimensional  array  F  and  the  first  dimension  of  two  dimensional  array  G  Similarly.  END  J 
defines  the  size  of  the  second  dimension  of  array  G. 

Use  of  free  subscripts  allows  an  array  to  be  defined  by  means  of  a  single  assertion  or  single 
conjunction.  It  is  important,  however,  for  the  variables  (be  they  arrays  or  scaler)  to  be  single 
valued.  Consequently,  a  conjunction  or  assertion  which  defines  multiple  values  for  arrays  is 

invalid  For  example,  the  assertion: 

ASR  f :  A ( I )  =  B(I.J)  TARGET :A( I) 

SOURCE : B( I , J) ; 

is  invalid  because  it  define s  an  element  of  array  A  to  be  equal  to  an  entire  row  | second 
dimension)  of  array  □.  In  general,  whenever  the  set  of  free  subscripts  associated  with  a  target 
variable  is  a  subset  of  the  number  of  free  subscripts  of  the  source  variables,  it  defines  multiple 
values  for  the  target  variable.  There  are  two  exceptions  to  the  above  rule: 

1.  when  a  source  variable  containing  an  extra  fiee  subscript  occurs  as  an  argument 
of  a  reduction  function,  and  the  extra  free  subscript  is  reduced:  or 

2.  when  a  boolean  condition  precedes  the  assoition  A  warning  is  issued  in  this  case 
and  it  is  the  responsibility  of  the  user  to  ensure  that  the  target  variable  is  single 
valued. 

Example  of  an  assertion  containing  a  reduction  function  is: 
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ASRT  :  F( I )  =  SUM(G( I , J) , J) 

TARGET : F( I) 

SOURCE :G( I , J) ; 

Reduction  function  SUM  takes  two  dimensional  array  G  and  sums  the  elements  of  the  same  I 


index  value,  thus  producing  a  one  dimensional  array  F.  The  array  variable  F  is  single  valued 
even  though  the  source  variable  G  has  an  extra  subscript  J  Example  of  the  second  exception 
is 


ASRT:  IF  END_I(I)  THEN  OUT  =  F(I) 

TARGET -.OUT 

SOURCE : F ( I ) , END_I ( I ) ; 

OUT  is  defined  by  the  last  element  of  the  array  F.  1  lowever,  it  is  the  responsibility  of  the  user  to 
make  sure  that  OUT  is  not  defined  by  more  than  one  element  of  F  Nopal  program  generator 
does  no  further  analysis  to  check  that  it  is  indeed  so. 


The  Logic  component  of  a  test  specifies  the  selection  of  diagnoses  The  diagnoses  are 
selected  depending  on  whether  the  test  evaluates  to  true  or  false.  The  test  evaluates  to  true  if 
all  the  assertions  in  the  test  evaluate  to  true,  and  false  otherwise  The  operators  given  in  Table 
4  1  may  be  specified  with  each  of  the  diagnoses  for  their  selection. 

The  logic  component  is  specified  by  a  list,  each  of  whose  elements  consists  of  an  operator 

followed  by  a  diagnosis  name  For  example: 

LOGIC  :  *01.  |D2,  ~D6; 


4.3.3  DIAGNOSES 

The  diagnoses  are  used  to  report  the  result  of  tire  test,  to  isolate  failure  modes  or  to  elicit  a 
response  from  the  user  It  has  five  parts  which  can  be  specified  in  any  order. 

1.  List  of  affected  components  and  their  failures  modes  which  are  isolated  by  this 
diagnosis.  They  may  be  in  conjunctive  or  disjunctive  form  where  the  former 
means  that  all  the  components  in  the  list  have  failed,  while  the  latter  that  at  least 
one  has  failed. 


\  a 
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Table  4-1 :  LOGIC  OPERATORS  IN  A  TEST 


OPERATOR 


MEANING 


& 


Select  the  diagnoses  unconditionally  i.e.  irrespective  of  the 
outcome  of  the  test. 

Select  the  diagnoses  if  the  test  evaluates  to  true. 

Select  the  diagnoses  if  the  test  evaluates  to  false. 

Mark  the  diagnoses  as  selected  if  the  test  evaluates  to  true. 
The  diagnoses  should  be  executed  only  if  all  other  tests  which 
use  this  diagnoses  (with  operators:  &  or  A  ~)  also  mark  it  as 
selected. 

Mark  the  diagnoses  as  selected  if  the  test  evaluates  to  false. 
The  diagnoses  is  executed  only  if  all  other  tests  which  use  this 
diagnoses  (with  operators:  &  or  &  -)  also  mark  it  as  selected. 


2.  Name  of  the  message  to  be  printed  The  message*  itself  is  specified  separately. 

3.  Parameters:  This  specifies  the  variables  whose  values  must  be  substituted  in  the 
message  at  the  appropriate  places. 

4.  Operator  response:  It  specifies  the  response  from  the  operator  when  the 
generated  program  is  executed  The  program  waits  for  a  response.  Response 
can  be  of  three  types: 

a.  press  PROCEED  key, 

b.  press  Y(yes)  or  N(no);  or 

c.  enter  a  number. 

Pressing  the  PROCEED  key  simply  causes  the  program  to  continue  execution.  It 
is  typically  used  to  turn  knobs  and  set  switches  manually,  i.e  those  which  cannot 
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be  controlled  by  ATE  Y  or  N  response  is  typically  used  for  asking  the  operator  to 
make  a  binary  choice.  The  response  (c)  is  usually  used  to  enter  reading  of  meters 
etc.  manually,  i.e.  those  which  cannot  be  taken  by  ATE. 

5.  Time:  Specifies  the  real  time  which  must  elapse  from  the  start  of  a  test,  before  the 
message  is  issued. 


Except  for  the  name  of  the  message  and  the  parameters  it  takes,  if  any.  all  the  other  parts 
of  the  diagnosis  are  optional. 


A  diagnosis  specification  is  illustrated  below: 

DIAG  D1 : 

AFFECTED  COMPONENTS  =  0PEN( RES ISTOR 1 ) | 0PEN( RESIST0R2 ) , 

PRINT  =  MSG1 , 

PARAMETERS  -  V, 

TIME  =  0; 

It  specifies  that  at  least  one  of  two  resistors  RESISTOR  t  or  RF5IS fOR2  has  failed  due  to 


open  circuit,  and  that  message  MSGi  with  parameter  V  must  be  printed.  lime  0  specifies  that 


no  time  delay  is  necessary  in  issuing  the  message 


4.3.4  MESSAGE  SPECIFICATION 

This  specification  consists  of  the  text  of  a  message,  and  parameters  and  affected 
components,  if  any  It  implies  the  printing  of  the  message  including  the  affected  components 
and  parameters. 


For  example,  the  message  MSGl  of  Section  4.3.3  can  be  specified  as  follows: 
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MESSAGE  MSG1 : 

'  ONE  OF  THE  FOLLOWING  FAILURES  HAS  OCCURED:  (C).  THE 
MEASURED  VOLTAGE  IS  (P) .  ’  ; 

When  the  above  message  is  punted  "(C)"  is  substituted  by  "OPEN 
(RESISTOR I  )|OPEN(RE:SISTOR2)"  and  "(P)"  is  substituted  by  the  value  of  variable  V 

4.4  UUT SPECIFICATION 

Information  relating  to  the  UUT  is  specified  in  this  section.  This  allows  various  consistency 
checks  to  be  performed  within  the  module  It  is  organized  in  two  parts:  (I)  interconnecting 
points,  which  are  used  for  identification  of  the  connection  points  of  the  UUT  to  the  ATE  (2) 
component  failures  which  identify  all  possible  faulty  components  with  the  failure  inodes  (i.e. 
types  of  failures). 

A  UUT  connection  point  defines  a  symbolic  name  lor  a  connection  point  on  UUT.  the  type 
of  connector  used,  and  the  maximum  and  minimum  value  ol  the  stimuli  which  may  be  applied 
on  it  For  example: 

UUPT  40  :  Jl.  CONNECTOR^ ( A) .  LIMIT- (VOLT ,70,0, GND) ; 

J1  is  the  name  by  which  this  connection  point  is  referred  to.  its  type  of  connector  is  A.  and  the 
maximum  and  minimum  value  of  stimuli  that  may  be  applied  with  nc.pect  to  the  ground  (GND) 
is  TO  volts  and  0  volts  respectively. 

In  UUT  component  failure  section,  all  possible  faulty  components  and  their  failure  modes 
are  listed.  Each  component  specification  includes  the  failure  mode,  likelihood  o!  the  failure, 
and  protection  Protection  consists  of  a  list  of  other  components  whose  failure  prohibit 
testing  of  this  component  t  or  example: 
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COMPONENT  FAILURE  2: 

RESIST  OR  1 ,  FAIL=0PEN ,  INDEX»1,  PROT  =  ( 1,11); 

specifies  that  the  component  RESISTOR!  has  a  failure  mode  called  OPEN,  the  frequency  of 
failure  is  1  (the  lower  the  number  the  larger  the  likelihood),  and  that  should  the  components  1 
or  1 1  fail,  tests  for  failure  of  this  component  must  not  be  conducted. 


4.5  ATE  SPECIFICATION 

Information  relating  to  the  Automatic  Test  Equipment  and  the  functions  used  in  a  module 
(computational,  stimuli  oi  measurement)  is  stated  here.  It  lias  two  parts:  (1)  ATE  connection 
point  specification,  and  (2)  functions  ATE  connection  point  specification  consists  of  the 
names  of  the  ATE  connections  points  Optionally,  the  specification  includes  identifying  ATE 

points  of  the  respective  UUT  points  In  the  example  below: 

ATEPOINT  1:  ATEPT03O,  UUPTS=( J1 , J2) ; 

"ATEPT  tt  30"  may  be  connected  to  UUT  points  J 1 . J2  The  checking  lor  the  UUT  points  has 
not  been  implemented  It  is  used  purely  as  a  documentation  device. 

Eunctions  user)  for  (1)  stimuli.  (2)  measurement  or  (3)  computational  purposes,  and  (4)  for 
denoting  failures  are  declared  in  the  ATE  function  specification.  Functions  in  the  first  three 
categories  are  assumed  to  be  defined  either  by  means  of  ofhet  modules  or  by  means  of  a 
library  of  functions.  The  failure  func  tions  (category  (4))  are  for  the  purpose  of  denoting  kinds 
of  failure.  They  are  not  functions  in  the  sense  of  the  earlier  three  categories. 

f  unction  specification  has  an  item  called  I  YPl  which  specifies  which  of  the  above  4  types 
does  the  function  belong  to.  and  items  (’ARM  and  VALUE  Rl  IURNED  to  specify  the  data 
typos  of  the  parameters  arid  the  value;  to  he  n  turned  The  number  of  pins  used  may  also  be 
specified  if  the  function  is  of  type  stimuli  nr  m  -a surement 
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For  example  a  function  PUSH! 

FUNCTION  PUSH.  TYPE=E .  PARM=( INSTACK, S tSTACK) , 

PARM=(ELEM,S, INTEGER) .VALUE  RE  TURNED- (STACK ) ; 

is  of  type  evaluation.  It  has  two  parameters,  both  source,  with  the  data  types  STACK  and 

INTEGER,  anti  it  returns  a  value  of  type  STACK.  The  names  INSTACK  and  EL  EM  have  no 

significance  for  the  specification.  Their  use  is  only  for  providing  mnemonics. 


Chapter  Five 


THE  NOPAL  PROGRAM  GENERATOR 

5.1  OVERVIEW  OF  THE  PROGRAM  GENERATOR 

The  Nopal  program  generator  is  designed  to  automate  the  program  design,  coding  and 
debugging  phases  of  program  development  based  on  a  specification  in  the  Nopal  language. 
The  program  generator  analyzes  a  Nopal  module  specification,  issues  a  number  of  reports  for 
the  user  and,  if  the  module  is  error  free,  generates  a  program  in  the  Equate  Atlas  test 
programming  language. 

There  are  three  phases  in  the  program  generation  process.  Phase  1  consists  of  syntax 
analysis  and  construction  of  internal  data  structures.  Phase  2  consists  of  analysis  of  the 
specification  for  completeness,  consistency  and  non-ambiguity;  and  of  sequencing.  In  phase 
3  Equate  Atlas  code  is  generated.  A  number  of  user  reports  are  issued  by  each  of  the  phases. 
The  three  phases  are  described  individually  in  Sections  5.2,  5.3  and  5.4.  More  detailed 
documentation  is  provided  in  [46], 

The  Nopal  processor  has  evolved  through  numerous  revisions  over  the  past  several  years. 
The  research  reported  here  includes  extending  the  original  system  [7]  with  the  following 
capabilities: 

1 .  Modules  to  provide  modularity  and  abstract  data  type  definition  facility. 

2.  Recursive  assertions  to  allow  the  arrays  to  be  defined  recursively. 

3.  Declaration  of  data  types  and  data  structures  as  well  as  virtual  subscripts. 
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Figure  5- 1 :  OVER  VIEW  OF  NOPAL  PROCESSOR 


5.1  OVERVIEW  OF  THE  PROGRAM  GENERATOR 


PHASE  1  : 


PHASE  2  : 


PHASE  3 


Figu  re  5- 2 :  MAJOR  PHASES  OF  NOPAL  PROCESSOR 
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4.  Input  output  from  secondary  storage. 

5  Virtual  subscripts  for  efficient  utilization  of  memory 

These  extensions  entailed  modifying  some  parts  of  the  original  system  and  completely 
rewriting  other  parts  In  particular,  the  scheduling  algorithm  was  completely  rewritten  to 
handle  recursive  assertions  and  input  output  from  secondary  storage  It  is  described  in 
Section  5.3.2. 

The  code  generator  was  not  implemented  in  thi  original  system  )7j  but  completed  later 
[513 1  The  Nopal  system  was  demonstrated  on  an  actual  Equate  Atlas  machine  1 15) 

5.2  SYNTAX  ANALYSIS  AND  THE  ASSOCIATIVE  MEMORY 

5.2.  t  OVERVIEW 

The  first  phase  of  the  Nopal  processor  performs  syntax  and  local  semantic  analysis  of 
specification  statements.  At  the  end  of  the  analysis,  each  Nopal  statement  is  encoded  and 
stored  in  a  simulated  asim,  uitiv;  memory  for  ease  of  further  processing  I  he  first  phase 
includes  a  Syntax  Analysis  Program  (SAP)  SAP  itself  is  generated  automatically  by  a 
meta  processor  called  Syntax  Analysis  Piogram  Generator  (SAPG).  by  inputting  the  formal 
specification  of  the  Nopal  language  in  a  meta  language,  called  Fx tended  Backus  Normal 
Form  with  Subroutine  Calls  (EE3NF /WSC)  SAPG  and  SAP  aie  described  m  Set  tion  5.2.2 

SAP  incorporates  six  types  of  supporting  routines,  which  are  composed  manually:  l  exical 
Analyzer,  Error  Stacking.  Recognizer,  Encoding/Saving/Stomuj  Semantic  Checking  and 
Service  Routines  These  are  described  in  Section  5.2.2. 

At  the  end  of  eac  h  Nopal  statement,  a  storing  routine  is  invoked  to  store  the  statement  in 
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the  simulated  associative  memeory  using  the  Store/Retneve  package  The  Store/Detrieve 
package  and  the  associative  memory  is  described  in  5.2.4. 

Finally,  the  set  of  repoits  generated  by  this  phase  are  described  in  5  2  5 

5.2.2  SYNTAX  AN Al  YSIS  PROGRAM  •  SAP 

SAP  is  generated  by  the  Syntax  Analysis  Program  Generator  (SAPG)  The  input  to  SAPG  is 
the  specification  of  the  Nopal  language  in  the  metalanguage  FFJNF/WSC  SAPG  and 
EBNF/WSC  were  originally  developed  at  the  University  of  Pennsylvania  Data  Definition 
Language  Protect  [43]  [44]  A  brief  review  of  EBNF/WSC  and  SAPG  is  given  below. 

EBNF/WSC  extends  the  standard  EBNF  to  piovide  semantics  1  he  semantics  is  specified 
by  means  of  subroutine  names  which  are  included  in  the  productions,  along  with  the 
terminals  and  non  terminals  These  subroutine  names  indicate  the  need  to  call  the  respective 
subroutine  upon  successful  recognition  of  the  preceding  syntactic  unit  by  the  parser  For 
example,  the  production 
<A>  •  <B>  /aa/  <C> 

indicates  that  a  subroutine  named  "aa"  needs  to  be  called  on  successful  recognition  of  the 
non  terminal  <B>  in  the  process  of  recognizing  the  non  terminal  <A>  The  subroutines 
themselves  are  written  manually. 

SAPG  accepts  the  specification  in  EE3NF/WSC  and  generates  a  recursive  descent  parser 
to  recognize  the  syntax  defined  by  the  EBNF.  Calls  are  inserted  to  the  subroutines  on 
recognition  of  non  terminals  as  specified  fry  EBNF/WSC  specification.  SAPG  requires  that 
the  EBNF  grammer  must  be  in  LL(1)  form  The  grammer  should  be  free  of  left  recursion,  and 
the  first  terminal  symbol  should  distinguish  between  the  optional  groups  at  any  point  in  the 


grammer. 
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5.2.3  SUPPORTING  SUBROUTINES 

The  EBNF/WSC  specification  contains  names  ot  subroutines  which  are  called  from  SAP. 
They  can  be  categorized  into  six  types; 

1  /  exicdl  analyser  scans  the  Nopal  input  string  and  returns  tokens  of  syntactic  units 
to  SAP  or  the  recognizer  routines. 

2.  Error  message  stacking  ivutmes  help  compose  and  stack  error  messages  before 
every  syntactic  unit  in  the  specification  In  case  of  mcoirect  nr  missing  syntactic 
units,  SAP  generates  tire  ei  ror  message  from  tire  error  stack 

3.  Recogm/er  routine:;  recognize  a  class  of  input  tokens,  such  as  names  and 
.otegers  These  occur  in  productions  of  the  form: 

<A>  -  /RR/ 

where  RR  is  the  name  of  a  recognizer  routine. 

•1  Friending  'snving/r.inring  muin ><\s  save  the  tokens  in  appropiiate  data  structures 
and  finally  in  associative  memory  for  purposes  of  later  analysis. 

5.  Semantic  chrcknig  nninnos  check  ttre  local  semantics  of  a  Nopal  statement. 

6  Service  routines  are  used  by  SAP  to  perform  sonre  internal  services  e  g  popping 
the  error  stack. 

At  the  end  of  each  Nopal  statement  a  storing  routine  is  called  by  SAP,  which  in  turn  calls 
STORE  to  enter  the  information  relating  to  ttre  present  statement  into  the  associative  memory. 

5.2.4  ASSOCIATIVE  MEMORY  AND  STORE/RETRIEVE  SUB  SYSTEM 

The  Store/Retrieve  Subsystem  is  a  generalized  means  of  storing  the  Nopal  source 
statements  and  later  retrieving  them.  It  consists  of  two  types  of  routines: 

1  STORE  for  storing  the  source  language  strings,  including  tokens  am)  entities, 
gathered  during  the  syntax  analysis,  and 

2  RETRIEVE  for  retrieving  the  source  strings,  and  for  accessing  the  "directory 
entries",  the  former  is  through  RETREVS  and  the  latter  through  RE  TREVD. 


The  STORE  routine  is  called  to  create  or  add  to  the  associative  memory,  and  RETRIEVE  to 
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Figure  5-3:  FLOWCHART  OF  SAPG  AND  SAP  WITH  SUBROUTINES 


5.2.4  ASSOCIATIVE:  MEMORY  AND  STORE /RETRIEVE  SUB  SYSTEM 
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access  or  modify  it 

There  are  eighteen  classes  of  statements  and  names  in  Nopal  A  list  of  classes,  their 
mnemonics,  and  the  entities  they  represent  is  given  in  Table  5  1  For  example,  class  15 
represents  the  variables,  and  class  2  represents  the  tests  An  identifier  occurring  in  two 
different  classes  denotes  two  different  entities.  In  oilier  words,  a  name  together  with  its  class 
uniquely  identifies  an  entity. 

A  directory  is  used  to  store  all  the  names  and  their  classes.  It  is  organized  as  a  binary  tree 
according  to  the  lexicogiaphic  order  of  entries  Ear  h  node  of  the  tree  corresponds  to  a  name 
and  its  class  There  are  <  loss  links  in  this  tiee  which  connect  all  nodes  with  the  same  name 
together  and  all  nodes  of  the  same  class  together.  Each  node  has  an  additional  link  (called 
RETI  1ST  in  Figure  5  4)  to  a  storage  entry  containing  this  name  and  type. 

There  is  a  s/omei-  entry  for  each  Nopal  source  statement.  It  contains  the  names  (KEY)  of 
all  the  symbols  (rather  pointers  to  the  names  in  the  directory)  which  occur  in  a  the 
corresponding  statement  With  each  symbol  name  it  has  a  pointer  (called  NEX1 )  which  points 
to  another  storage  entiy  which  uses  it.  Thus,  it  provides  a  very  <  fficient  means  to  find 
occurrences  of  symbols  in  different  statements  Associated  with  each  storage  entry  there  is 
also  a  pointer  (DATA)  which  points  to  the  entire  parsed  source  string,  stored  in  a  separate 
data  area. 

The  storage  entries  together  with  the  directory  and  the  data  aiea  is  called  the  associative 
memory. 

As  mentioned  in  the  previous  section,  STORE  is  called  at  the  end  of  each  Nopal  statement 
Its  arguments  are  (1)  a  li.d  of  names  ami  their  classes  encountered  in  the  statement,  and  (2) 
pointer  to  the  data  area  containing  the  parsed  source  statement  It  enters  the  names  and  their 
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Table  5-1 :  CLASSES  OF  NAMES  AND  THEIR  TYPES 


CLASSES 

MNEMONIC 

CLASS  OF  ENTiTIF.S  FEiTT!  ENTED 

1 

SPEC# 

NOPAL  specification  label/ statement 

2 

TEST  ft 

Test  module  label/ statement  or  modfun  header 

3 

STIM# 

Stimulus  label /state men t 

4 

MEAS" 

Ffeasuremen t  label/ statement 

5 

DIAG# 

Diagnosis  label/stateircnt  _ 

6 

MSG# 

Message  labcl/statenent 

7 

LOGIC# 

Logic  label/ statement 

8 

OONJ# 

Conjunction  label/statement 

9 

ASRT# 

Assertion  label/statement 

10 

COMP# 

UUT  component  identifier  (id) 

11 

CMPFL" 

Component- failure  (i.e.  affected  component) 

id/staterr.ent 

12 

UUTFr# 

UUT  connection  point  id/staterr.ent 

13 

ATEPT# 

ATE  inter- connection  point/id  statement 

14 

FUN'C# 

Function  id 

15 

VAR# 

Variable  id 

16 

END# 

End  statement 

17 

dtyp# 

data  type  name 

18 


rec  # 


data  declaration  statement 
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(a)  DIRECTORY  ENTRY 


JCoy-antrv  ^  Tre.c-lir.l-  Cre^-lin k 


Keyname 

Key  class 

Ref list 

Up 

Down 

N  ext- 

Next  - 

name 

type 

(b)  STORAGE  ENTRY 


Key entry  (1)  Key entry (-keys) 


t - A - ^ 

r - * - n 

Data 

i?  keys 

1 

i 

Key  !  Next 

L 

i 

1 

Key  J Next 
l 

/I 

' 

Other  data 


Figure  5-4:  STRUCTURE  OF  THE  DIRECTORY  AND  STORAGE  ENTRIES 
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classes  into  the  directory,  and  creates  a  stoiaye  entry  corresponding  to  the  statement.  The 
storage  entry  contains  the  names  (rather  pointers  to  the  names  in  directory)  which  occur  in 
this  statement.  STORE  then  proceeds  to  create  all  the  association  links  corresponding  to 
each  of  the  names,  and  also  to  store  the  pointer  to  the  data  area  in  the  storage  entry 

The  two  procedures  RETREVD  and  RETREVS  allow  the  information  to  be  retrieved  from 
the  associative  memory  The  former  retrieves  pointers  to  directory  entries,  and  the  latter 
retrieves  storage  entries.  Entries  can  be  retrieved  by  logical  expressions  of  their  names  and 
classes.  For  example,  all  entries  belonging  to  a  certain  class  which  do  not  occur  in  some 
statement  class  can  be  retrieved  by  constructing  an  appropriate  logical  expression. 

5.2.5  REPORTS 

Listings  of  the  specification  and  errors  encountered,  if  any.  in  the  specifications  arc 
reported  at  the  end  of  the  Syntax  Analysis  Phase.  I  ho  programs  XREF 1  and  XREF2  generate 
a  cross  reference  listing,  and  the  program  SOURCE2  generates  a  formatted  listing  of  the  user 
specification.  Samples  of  these  reports  are  shown  m  examples,  in  the  Appendix. 

XREF1  also  determines  the  scopes  of  variables  i.e  whether  the  variables  are  global  or 
local,  and  enters  it  in  ttie  data  areas  of  the  associative  memory. 


5.3  SPECIFICATION  ANALYSIS  AND  SEQUENCE 
DETERMINATION 

5.3.1  OVERVIEW 

Phase  2  of  the  Nopal  processor  analyzes  a  Nopal  spec if u  ation  and  determines  the 
sequence  of  execution  of  the  statements  The  analysis  is  based  on  a  graph  representation  of 
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ttie  specification,  i  Ins  section  presents  tin.'  background  and  terminology  used  in  this  phase. 

Phase  2  is  divided  into  two  sub  phases  In  sub  phase  t  each  of  tin-  tests  is  analyzed,  and 
in  sub  phase  2  the  relations  between  tests  within  a  modfun  are  analyzed  f  lie  sub  phases  are 
called  in/ra  te  a  .iiuvy-.is  and  mlri  tn\,!  .mr'y  v.  respectively  In  the  mt.a  test  tnalp.is  a  graph 
is  constructed  tor  each  ol  the  tests  Nodes  of  the  graph  represent  variables,  assertions, 
coniunctions  amt  diagnoses;  and  the  edges  represent  precedence  relationships  between 
them  In  the  inter  test  analysis  on  the  other  hand  the  nodes  nl  the  giapli  represent  tests, 
diagnoses  and  global  vai tables,  and  the  edges  represent  pine. -doice  relationships  between 
tlv >in  Edges  in  both  the  sub  phases  are  lab-  -lied  to  denot"  the  different  types  of  precedence 
relationships. 

The  Nopal  processor  stores  the  graph  in  a  matin'  form  the  rows  an  I  colnumns  topics. -nt 
the  nodes,  and  the  entries  ...  the  matrix  n  present  edges  A  non  /i.iio  entry,  say  n  in  the 
position  (i  |)  in  the  matrix  i ..presents  an  edge1  ol  type  n  fiom  node  i  to  node  |  while  a  zem  entry 
denotes  the  absence  of  an  edge 

Alter  the  graph  is  c  on'. true  ted.  it  .  oheci'od  for  r-onsistt -nr.  y  and  r  omplet.-ness  It  is  then 
r*  jckerl  tor  cycles  and  an  attempt  is  made  to  eliminate  them  f  mi. ill, .  if  sue res'-iul  the 
nodes  are  entered  in  an  i.'.'cuhon  sequeiis,.'  fun  me  t'on  of  llw  gtaphs  .  ou  islens,  and 
completern ss  analysis.  cycle  elimination  and  sequencing  ; i r < •  d.",i.  ••:.  d  for  tin-  mtra  !>'st 
sill)  phase  in  Rectum  5.3  /  and  for  the  intei  test  sub  phase  m  '  S.  turn  5  3  3  I  .gore  5  5  shows 
a  flowchart  of  the'  processes  involved  in  graph  analysis  and  ■  •  gueiK  n .< ; 

5.3.2  INTRA-  N.ST  ANAL  Y  SIS  AND  SEQUENCING 

i  ar  li  oi  the  tests  m  a  .specification  is  analyzed  in  tins  suh  phase  In  podium  .analysis  and 


gwenr  iihj.  a  graph  is  (.on  si  rue  led  lor  each  of  the  tests  Nodes  of  a  graph  ai  e  conjunctions. 
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assertions.  variables  and  their  ancestors,  and  diagnoses  associated  with  the  test.  There  are 
six  types  of  p  ecedence  relationships  between  nodes,  which  arc’  represented  by  edges  in  the 
graph  Table  5-2  shows  the  edge  types  and  the  relationships  that  they  represent.  A  priority  is 
associated  with  each  edge.  1  denotes  the  highest  priority  and  6  denotes  the  lowest.  Edges 
with  priority  1  are  considered  mandatory  and  cannot  be  deleted  Edges  with  lower  priority  are 
not  essential  and  can  be  deleted  during  the  cycle  elimination  stage:  they  represent  preferred 
relationships  rattier  than  mandatory  ones. 

Relationship  of  < /ala  deteiminncy  exists  between  vauables  on  one  hand  and  conjunctions, 
assertions  and  dignoses  on  the  other  A  variable  node  is  the  predecessor  ot  conjunctions  and 
assertions  if  it  occurs  as  a  source,  and  is  succ  essor  if  it  occurs  as  a  target  in  them.  Similaily. 
a  variable  is  predecessor  of  a  diagnosis  if  it  occurs  as  a  parameter,  and  is  successor  if  it 
occurs  in  the  operator  response.  The  relationship  of  data  dolerminacy  expresses  the  idea 
that  a  variable  must  be  defined  before  it  is  referenced. 

Relationship  of  waveform  .setup  exists  between  the  stimulus  conjunction  and 
measurement  conjunction.  It  is  not  mandator  y  and  is  of  priority  2.  It  expresses  the  notion  that 
stimulus  is  usually  applied  before  the  measurements  are  matte. 

Relationship  of  diagnosis  waveform  exists  between  diagnosis  on  one  hand  and 
conjunctions  and  assertions  on  the  other  This  relationship  is  entered  as  type  16  or  17  A 
diagnosis  which  is  selected  unconditionally  on  the  outcome  of  a  test  precedes  each  of  the 
conjunctions  and  assertions  in  the  test  try  an  edge  of  type  16  A  diagnosis  which,  on  the  other 
hand,  is  selected  try  the  logic  |.  |~.  8  and  &  •  succeeds  each  of  the  conjunctions  and 
assertions  by  an  edge  of  type  1 7. 


All  the  unconditionally  selected  diagnoses  precede  all  othoi  diagnoses  by  edges  of  type 


1 
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TABLE  5.2  INTRA-TEST  PRECEDENCE  RELATIONSHIPS 


EDGES 

SELECTION  RULE 

4- - - 

TYPE 

PRIOR¬ 

ITY 

RELATIONSHIP 

PREDECESSOR 

SUCCESSOR 

1 

1 

Data- 

determinacy 

Source  variable  in 
an  assertion 

The  assertion 

An  assertion  having 
a  target  variable 

The  target 
variable 

A  var i able  in  a 
parameter  of 
diagnos is 

The  diagnosis 

A  diagnosis 

Variable  in 
opera  tor 
response  of 
the  diagnosis 

2 

2 

Wave  for  ru¬ 
se  tup 

Stimulus- 

conjunction 

Measurement- 

conjunction 

16 

5 

Wave  form- 
diagnosis 

Diagnosis  selected 
by  *  logic 

All  waveforms 

17 

5 

All  waveforms 

All  d iagnos  e  s 
not  selected 
by  *  logic 

18 

5 

Diagnoses  selected 
by  *  logic 

All  other 
d i a  gnos  e  s 

19 

1 

Hierarchical 

Node  in  an  input 
structure 

declaration 

All  its  direct 

descendent 

nodes 

Node  in  an  output 
structure 

Its  parent 
node  in  the 
structure 

k 
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TAM.E  5.2  (continued) 


20  i 

1 

1  : 

Pointer 

: 

Po  int  r  varialil  o 
( i . e .  variable  with  1 

prefix  PTH  or 

PTRy  ,  where  y  in  a 
digit  1  to  5) 

5  t  r  u  c  t  u  i  e 
!  (or  which  t  !  i  ■ 
i  pointer 
variable  i  r, 
a  key  or 
pa  r  a  m*.'  ter 
( tj  i  vo  n  b  y  t  li  e 
suffix  of  the 
|>oi  a  l.e  r 
variable) 

21 

6 

Recursive* 

A  source  variable 
in  an  assertion 
with  subscript  of 
the  form  I -k  , 
where  k  is  positive 
integer 

[ 

Th  <>  assertion 

Table  5-2:  INTRA  TEST  PRECEDENCE  RELATIONSHIPS 


0  This  relationship  is  originally  entered  as  type  l.  but  is 
changed  later  to  type  21  in  the  subscript  analysis  phase. 
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1 


t 


18. 


Relationship  between  nodes  in  a  data  structure  is  called  hiorarchichai,  and  is  entered  as 
edge  of  type  19.  A  node  in  a  structure  precedes  each  of  its  direct  descendents  in  an  input 
structure,  and  succeeds  each  of  its  direct  descendents  in  an  output  structure. 

Pointer  relationship  exists  between  a  variable  which  is  a  key  of  an  ISAM  file  and  the  record 
node  of  the  ISAM  file.  It  is  entered  as  type  20  edge. 

Certain  data  determinacy  relations  are  identified  as  roi  uns/w  and  are  entered  as  type  21 
edges  They  are  mentioned  here  for  the  sake  of  completeness  and  aie  desciibed  later  after  a 
discussion  of  array  graph. 

An  array  is  represented  by  a  single  node  in  the  graph-  An  array  variable  is  represented  as  a 
single  node  independent  of  its  dimensions,  similarly  an  assertion  is  represented  by  a  single 
node  irrespective  of  the  free  subscripts  which  occur  in  the  assertion  Edges  in  the  graph 
represent  relations  between  the  nodes.  An  edge  between  two  nodes,  when  at  least  one  of  the 
nodes  represents  an  array  variable,  denotes  an  array  of  relations  (array  relations)  between  the 
two  nodes.  A  graph  whose  nodes  represent  array  variables  and  whose  edges  represent  array 
relations  is  called  an  array  graph. 

The  intuitive  notion  of  array  graph,  introduced  above,  can  br  made  more  precise  in  terms 
of,  what  is  called,  the  underlying  graph  (IJG)  of  a  specification.  A  variable  node  of  a  UG 
represents  a  simple  variable,  conjunction,  assertion,  or  diagnosis.  In  other  words  if  B  is  an 
array  variable  of  two  dimensions  of  size  5  and  10  each  respectively,  then  a  separate  node  is 
needed  in  the  UG  to  represent  each  of  the  50  elements  of  B  similarly,  for  conjunctions, 
assertions  and  diagnoses  which  have  free  subscripts  and  express  array  of  relations  between 


array  variables,  a  node  represents  an  element  of  the  array  of  relations,  e  g.  if  13  is  an  array  as 
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before  and  it  occurs  in  a  conjunction,  assertion  or  diagnosis,  then  there  will  be  50  nodes, 
each  representing  a  conjunction,  assertion  or  diagnosis  involving  one  element  of  B  Edges  in 
a  UG  represent  relationship  between  nodes  as  outlined  before  and  as  the  nodes  represent 
simple  entities  the  edges  also  represent  simple  relations. 

Array  giuph  (AG)  can  be  formed  by  taking  the  union  of  nodes  and  edges  in  an  underlying 
graph  as  follows:  represent  the  nodes  say  N  Vi.  in  UG  representing  different  elements  of  an 
array  variable  (or  conjunction,  asseition  or  diagnosis)  by  a  single  undo,  say  N.  in  the 
corresponding  array  graph  and  for  an  edge  from  any  of  the  nodes  N,  to  any  other  node,  say 
P,.  in  UG  form  an  edge  from  N  to  P  in  AG  (lie  resulting  smaller  graph  is  an  AG  of  the  given 
UG  Tfius,  AG  is  a  compact  way  to  represent  l)G  The  UG  may  bo  an  enormous  graph  winch 
is  impractical  to  analyze. 

An  array  graph  is  shown  in  F  iguie  5  C  It  is  for  the  familiar  PUSH  function  of  slack  data 
type  Nodes  S.Z.  «2  and  Sl.Z  are  array  nodes  in  the  example.  The  rest  ol  the  nodes  represent 
simple  variables  and  assertions. 


The  array  graph  Is  constructed  by  means  of  the  pt  ocedure  Iff  I GEQ  It  is  first  analyzed  for 
two  types  of  consistency  checks 

1.  Single  assignment  rule:  Variable  nodes  should  have  exactly  one  predecessor 
assertion  or  diagnosis,  i.e.  a  variable  should  tie  defined  by  e*a<  fly  one  assertion 
or  diagnosis  etc  (In  case  the  variable  is  part  of  an  input  structure  or  is  a  source 
parameter  of  the  modfun.  then  il  need  not  have  any  predecessor  in  the  graph.  In 
the  first  case,  the  input  file  Is  taken  to  he  the  implicit  predoimssoi  In  the  second 
case,  the  value  of  the  formal  parameter  is  defined  when  the  modfun  is  called  and 
lienee  it  does  not  tiave  a  predecessor  in  the  present  graph  ) 

2.  Target  variables  in  an  assertion  should  occur  either  on  the  left  hand  side  of  the 
relational  operator,  or  as  target  parameters  of  function  I  argot  variables  of  a 
conjunction  should  occur  only  as  parameters  ol  functions 
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1  NOPAL  POBULE  STaCA; 

2  m  1  SUU:  lECOIt, 

2  2  TOPE:  INIE5EA, 

2  2  1:  I N  7  £  6  E  A  A  A  A  A  T  (100); 

3  HO  D  E  UN  PUSH<S:S  STACK.  X:S  INTESEA)  RETURNS  (SI:  STACK); 

«  STin; 

J  A  5  R  T  :  1  *  SUBSl'S.T,  S 1 . 2 ■ END ' . 1 00 )  TAR6ET :J; 

t  «1  A  S  A  T  :  S1.T0P2  *  -TOPI  ♦  1  T  AA  S  E  T  :  S  1  .  TO  P I 

4  SOURCE:  S  .TOPI  ; 

2  o  ASAT:  If  J ■ S . TOP  I  THEN  S1.MJ)  »  A 

7  ELSE  SI.I(J)  =  S.I(J)  TAR6E T : Si  .7 <J> 

7  SOURCE:  S  .TOPI .S .1 ( J > ; 

s  a  3  ASAT:  IF  J*S.10PI  THEN  END.J(J)  =  TRUE 

g  ELSE  ENO.J(I)  =  FALSE 

g  1ARSET  :END_  J  (J  ) 

g  SOURCE  :S  .TOPI; 

*  tOSIC:  IB  un ; 

10  OIAC  8 un :  print  *  nsfc; 


I- 1  hierarchichal  edge 
D  data  determinacy  edge 
WD  waveform  diagnosis  edge 


Figuro  5-6:  SPECIFICATION  OF  PUSH  AND  ITS  ARRAY  GRAPH 
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Subscript  analysis  is  performed  by  the  procedure  SUHANAI  F  list  i!l  the  decimation; 
free  subscripts  are  checked  for  correctness  re  that  no  subscript  is  de-Jar  ei i  twice  and  t 
the  same  variable  dimension  is  not  used  in  two  subs*  opt  decimation:.  ("mall,  a  table  of 
ttie  free  subscripts  is  constiucted  containing  then  nanu  s  and  upper  I  •minds 


Further  cfiecks  of  the*  free  subscripts  are  condor  tod  by  the  pror  ••dure  SUfiUGAG 

follows: 

t  All  oia  mrences  of  a  target  vaiiahlo  in  an  asseition  01  cnnuini  tion  must  have-  the 
same  free  subset  ipt  I  or  example  In  the  assei  lion  (hum  I  ’I  IGH  •  •  .ample) 

IF  J  =  S .  TOPZ  THEN  Sl.Z(J)  ■=  X 

ELSE  Sl.Z(J)  =  S . TOPZ 
TARGET :S1.Z(J) ; 

variable  Si  7(1)  is  the  target  variable  oci  lining  in  both  the  1 1 II  I J  md  El  SI  parts 

2.  The  free  snbr.i  ripts  of  the  source  variatiles  must  appear  as  subscripts  with  the 
target  variables  There  are.  however.  two  exceptions  f  irst  a  free  subscript 
which  is  reduced  by  a  reduction  fun<  tion  need  not  appeal  as  a  ■  .i il >:;c  i ipt  of  the 
target  variable  Second,  in  an  if  asseition  or  if  <  nniiim  tion  the  free  subscript  of 
source  variatiles  need  not  appear  with  the  taiget  variables.  In  that  case,  a 
warning  is  isued  to  the  user  that  the  laiget  variable  should  be  c  her  '-ed  that  it  does 
not  have  multiple  definitions.  A  warning  will  be  issued  m  the  following  case 

IF  END.  J(  J )  =  TRUE  THEN  OUT  =  A(J) 

TARGET : OUT ; 

3.  Subscripts  must  be  in  one  of  the  following  forms 

a.  a  subscript  term  e  g  I  in  A(l): 

b  a  subscript  expression  of  the  form  (I  k)  where  I  is  a  Itee  sulc  rnnt  and  k  is  a 
positive  integer; 

c.  another  variable  e  g  B(l)  m  A(H(I))  or  X  in  A(X). 

4.  If  a  positive  integer  or  a  subscript  teim  appears  as  an  mdev  of  an  array  vaiiahlo  V, 
and  the  range  for  the  corresponding  dimension  of  V  is  det  l.ued  to  fie  d.  then  in 
case  oi  the  intogoi  its  value,  and  in  case  of  the  subscript  icrm  its  upper  bound, 
should  be  less  than  d  In  other  words,  a  subscript  expression  is  (  becked  to  see 
that  if  lies  within  the  range  lor  the  above  two  cases 
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The  array  graph  is  analyzed,  next,  for  cycles  by  the  CYCLES  procedure  If  a  cycle  i 

detected  in  the  graph  then  the  procedure  attempts  to  eliminate  it  Edges  in  a  cycle  havm 

pnority  value  greater  than  1  may  be  removed  These  edges  correspond  to  two  cases: 

1  The  edges  are  considered  as  preference  edges  and  are  not  essential  e  g  a  type 
2  edge  between  stimuli  coniunction  and  measurement  i  onjnction  denotes  the 
usual  situation  that  the  stimulus  is  applied  before  the  measurement.  However, 
there  may  be  situations  in  which  a  stimuli  depends  on  the  measured  value,  and 
can  only  be  applied  after  the  measurement  is  performed. 

2.  The  edges  do  not  imply  a  cycle  in  the  underlying  graph.  This  occurs  with 
recursive  edges  For  example,  the  array  graph  for  an  assertion  of  the  form: 

«:  IF  1=1  THEN  A(I)  =  1 

ELSE  A ( I )  =  I  * A ( I  —  1 ) 

TARGET :A( I); 

is  given  by  Figure  5  7  In  the  underlying  graph  recursive  edges  give  rise  to  acyclic 
spiral  like  structures. 


In  the  event  that  deletion  of  edges  fails  to  resolve  all  the  cycles,  an  error  is  reported  to  th« 
user  that  the  specification  contains  a  circular  definition  and  that  it  is  not  possible  to  sequence 
it  A  warning  is  issued  for  each  edge  deleted  in  the  cycle  elimination  process. 

Procedure  PROPAGT  determines  the  relation  between  the  nodes  and  the  free  subscripts 
in  order  to  find  the  proper  scopes  for  each  possible  iteration.  This  procedure  constructs  fo 
each  node  a  list  of  subscripts  on  which  it  depends,  and  hence  the  list  of  iterations  in  which  i 
should  participate.  In  tfie  Nopal  language,  iterations  result  from  explicit  appearance  o 
subscripted  variables  and  subscripts  themselves. 


The  final  stage  is  to  sort  the  nodes  into  a  possible  execution  sequence.  If  there  were  nc 
subscripts,  and  hence  no  iterations,  then  a  simple  topological  suit  would  be  sufficient.  The 
presence  of  subscripts  introduces  an  additional  factor  A  brute  force  approach  to  handle 
subscripts  is  to  enclose  each  node  in  the  iteration  scopes  of  its  subscripts,  with  the  exception 
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recursive  edge 


Figure  5-7:  RECURSIVE  EDGE 

that  the  nodes  belonging  to  a  recursive  cycle  (which  was  opened  during  cycle  eliniii 
stage)  must  be  enclosed  in  the  scope  of  a  common  subscript  iteration  The  algorithm  u 
the  Nopal  processor  does  better  than  the  brute  force  approach  and  tries  to  maximi, 
scopes  of  iterations  It  is  performed  by  the  procedure  SCHEDl  R  The  scheduling  proc 
described  below.  At  the  end  of  this  process  an  order  vector  is  generated  along  with  s 
and  subscripts  of  iteratons. 

There  are  ttiree  inputs  to  the  scheduling  process: 

1.  an  array  graph, 

2.  a  list  of  free  subscripts  for  each  of  the  nodes  and  a  list  of  nodes  for  each  free 
subscript,  and 

3  a  list  of  recursive  cycles,  where  for  each  recursive  cycle  there  is  a  list  of  nodes 
which  occur  in  it. 

The  scheduling  process  consists  of  two  procedures:  SCHEDL R  and  ORDERED.  SCH 
calls  on  ORDERED  requesting  trial  ordering  of  nodes  depending  on  a  subscript.  Oas< 
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the  results  of  the  trial  ordering,  SCHEDLR  calls  ORDERER  a  second  time  to  pt 
actual  scheduling  of  nodes. 

SCHEDLR  makes  use  of  a  stack  called  NEST,  which  contains  free  subscripts, 
stack  contains  free  subscripts  corresponding  to  which  iterations  have  begur 
iterations  are  nested  within  each  other,  with  the  free  subscript  on  top  of  the  Nf 
representing  the  innermost  iteration  Nodes  currently  being  ordered  by  ORDERER  ; 
within  all  these  iterations.  In  addition  to  the  NEST  stack.  SCHEDLR  also  lias  a  ; 
subscripts  called  TDNEST  It  contains  those  free  subscripts  which  are  candidates 
nested  at  the  innermost  level  in  the  iterations  corresponding  to  the  free  subscripts 
stack 

SCHEDLR  has  tfiree  phases.  In  Phase  t  it  picks  up  all  those  nodes  in  the  gr< 
have  no  predecessors,  and  finds  the  union  of  the  free  subscripts  associated  with  the 
subscripts  form  the  set  CANDl  1ST.  If  one  of  the  nodes  does  not  depend  on  any 
then  it  is  treated  as  belonging  to  subscript  free  set.  and  a  special  entry  ( vro)  is  ii 
CANDLIST.  From  the  set  CANDLIST.  another  set  called  E3ES\(  AtJDl  1ST  is  fori 
following  cases  are  performed  progressively  in  succession  until  t  non  empty  BLSTC 
results: 

1.  all  the  subscripts  in  set  CANDLIST  which  also  belong  to  I'VE  'd  are  place 

'  BESTCANDLIST; 

2.  a  subscript  in  the  CANDLIST  set  which  also  belongs  to  Nl  I VI  stack  is  place 

BESTCANDLIST; 

3.  if  entry  zero,  corresponding  to  subscript  free  nodes  belongs  to  CANDLIST 
placed  in  BESTCANDLIST;  otherwise 

4  all  entries  belonging  toCANDUST  are  placed  in  Hf  SFCANDt  1ST 
BESTCANDLIST  now  contains  Ihose  free  subscripts  which  are  possible  candidal 
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ordering  process. 

In  Phase  2.  SCHEDLR  calls  ORDERED  with  each  of  the  entries  in  RE  SIC 
perform  a  trial  schedule.  The  results  of  the  trial  schedule  are  evaluated  aero 
priority  table  given  in  Table  5.3. 

f.et  the  ORDERFR  be  called  to  perform  a  tn.il  ordering  with  a  a.hsr  i .(>t  1C  Lelo 
set  GESTCANDLIST  It  performs  a  trial  sell- -« ful»-  and  return- •  th-  •  l<  .»■.•.  m  ;  mfoi  ira 

1  whether  all  the  nodes  ifependiny  on  !e,  got  ..(Is  :u'  • :  •  •  whether  I1 

completely  tu'duloii; 

2  a  set  ol  other  subscripts.  IOC.  which  got  ■mi'U-ii  iy  ..  rn-d,.'.  ,1. 

3  a  set  of  other  subscripts.  IOP.  some  of  whose  nodes  got  st,  hod  tiler, 
subscripts  win;  h  got  ruOiaYy  ■  <  hi  JulecI:  and 

•I  whether  there  is  a  recuisive  cycle  some'  but  not  all  uf  whoso  node 

scheduled. 

A  priority  value  is  evaluated  based  on  the  above  results  as  per  I  able  5  3  (in  the 
true  if  condition  (1 )  is  satisfied,  and  CY  is  equal  to  0  if  condition  gl)  is  satisfied  i 

If  the  priority  value  is  I  then  the  SCHEDl  R  proceeds  to  Phase  3  to  call  IL--  1 
second  time  with  1C.  this  time  to  do  the  actual  ,,c  hedulmy  II  the  prior  it  •,  .  atm.  is  yr, 
then  trial  schedule  for  a  new  subscript  in  HERTCANDUST  in  dune  I  mall,  v. 
subscripts  in  BESTCANDLISl  have  been  trial  scheduled,  the  subscript,  say  IN.  will 
value  of  priority,  say  P,  is  chosen  If  P  is  equal  In  5  an  er  roi  message  is  issm  >d  that 
cycle  needs  to  be  broken  If  P  is  equal  to  4  a  warning  is  issued  indicating  to  tl' 
some  files  must  be  ontnely  located  in  the  mam  memory  I  or  other  values  of  I1  if  | 
Phase  3  of  SCHf  Dl  I!  to  do  the  at  trial  sc  hodulmg  with  subscript  Ilf 


Phase  3  corresponds  to  the  second  c  all  on  OBDEDF  R  to  do  the  actual  set 
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1C 

has 

CP  *  i 

IOP  =  NULL 

CY  =  0 

IOP  has  no  I/O 

CY  =  0 

IOP  has  I/O 

CY  -=  0 

CP 

I/O 

1 

2 

4 

no  I/O 

1 

2 

3 

-CP 

I/O 

4 

4 

4 

no  I/O 

2 

3 

3 

I/O  stands  for  input  ouput  Meaning  of  1C  IOP,  CP,  CY  etc.  is  explained  in  th< 


Table  5-3:  PRIORITIES  OF  THE  T  RIAL  SCUEPUI  F 
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nodes  Following  this,  the  nodes  which  got  scheduled  are  removed  from  the  graph.  Finally,  if 
some  nodes  still  remain  in  the  graph.  Phase  1  is  started  all  over  again. 

Procedure  ORDERER  is  described  next  It  has  two  modes:  (1)  to  perform  trial  scheduling, 
and  (2)  to  perform  actual  scheduling  of  nodes.  It  has  a  parameter.  1C,  which  gives  the  name 
of  a  free  subscript. 

In  mode  (1)  it  does  a  topological  sort  of  the  nodes  which  depend  on  the  subscript  1C.  It 
then  evaluates  the  result  of  the  trial  ordering  and  returns  the  result  in  CP.  IOC.  IOP  and  CY  as 
described  earlier. 

In  mode  (2)  it  performs  a  topological  sort  of  the  nodes  which  depend  on  the  subscript  1C, 
on  all  of  the  subscripts  in  the  stack  NEST  and  on  no  other  subscripts.  The  resulting  ordered 
set  of  nodes  is  added  to  the  ORDER  vector  and  removed  from  the  giaph. 

The  scope  of  iterations  is  determined  from  the  NEST  stack.  Each  time  an  entry  is  pushed 
on  the  NEST  stack  it  defines  the  beginning  of  a  new  iteration;  and  each  time  the  NES  T  stack  is 
popped  it  defines  the  termination  of  an  iteration.  The  NEST  stack  is  updated  as  follows: 

1.  Each  time  the  ORDERER  is  called  to  do  the  actual  scheduling  with  a  subscript  1C. 
an  entry  is  made  on  NEST  provided  1C  was  not  selected  by  case  (2)  in  Phase  2  of 
SCHEDLR. 

2.  The  NEST  stack  is  popped  (in  case(2)  in  Phase  2  of  SCHEDLR)  until  the  selected 
subscript  1C  is  on  top  of  the  NEST  stack. 

The  final  result  of  scheduling  process  is  an  order  vector  and  an  iteration  table  giving  the 
scopes  of  iterations.  They  are  used  by  the  code  generation  phase  (by  procedure  CDETEST 
described  in  Section  5.4)  to  generate  Equate- Atlas  code. 


I 
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In  this  sub-phase  a  graph  is  constructed  lor  the  entire  modfun  specification.  The  nodes  of 
the  graph  are  tests,  diagnoses  and  global  variables.  There  are  seven  types  of  precedence 
relationships  between  nodes.  They  are  described  in  Table  5.4.  The  table  gives  the  name, 
type,  and  priority  associated  with  a  precedence  relationship.  It  is  followed  by  a  description  of 
the  predecessor  and  successor  nodes  which  satisfy  the  relationship.  The  meaning  of  the 
terms:  type,  priority  etc.  is  the  same  as  discussed  in  Section  5.3.2.  The  seven  relationships 
are  described  below. 

Data  determinacy  relationship  exists  between  tests,  diagnoses  and  global  variables.  A  test 
or  a  diagnosis  is  the  predecessor  of  a  variable  if  the  variable  is  defined  by  one  of  them,  and 
successor  if  the  variable  is  used  as  a  source  by  them. 

Interactiveness  relationship  exists  between  a  diagnosis  and  the  test  which  selects  the 
diagnosis  by  "after"  and  "after  not"  logic  operator  (A  and  A~).  It  means  that  the  test  is 
selected  based  on  the  operator  response  to  the  diagnosis. 

Component  protection  relationship  exists  between  a  diagnosis  and  a  test,  if  the  test  has  an 
affected  component  which  is  protected  by  the  diagnosis.  Its  purpose  is  to  inhibit  testing  of  a 
component  if  another  component  which  protects  it  has  failed. 

Fault  isolation  relationship  exists  between  a  diagnosis  and  a  test,  if  the  set  of  affected 
components  of  the  diagnosis  contains  the  set  of  affected  components  of  the  test.  It  expresses 
the  idea  that  those  tests  which  isolate  smaller  number  ol  failures  should  be  performed  later 
compared  to  the  tests  which  isolate  larger  number  of  failures. 

Stimuli  application  relationship  exists  between  two  tests  if  one  of  the  tests  has  stimulus 
funcions  which  are  applied  more  frequently  than  those  in  the  other  test.  It  leads  to  performing 
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of  as  many  tests  as  possible  once  an  ATE  device  is  connected. 

Two  tests  are  related  by  means  of  failure  liklihood  relationship  if  the  predecessor  test 
isolates  those  failures  which  are  more  likely  to  occur.  The  liklihood  of  a  failure  is  supplied  by 
the  user  in  the  specification. 

Finally,  a  test  is  the  predecessor  of  a  diagnosis  selected  by  one  of  the  logic  operators:  |,  |~, 
&  and  in  the  test.  The  selection  of  a  diagnosis  by  means  of  one  of  the  above  logic 
operators  is  dependent  on  the  outcome  of  the  test.  This  is  expiessed  by  the  logic  operator 
relationship. 

Several  of  the  relationships  described  above  are  not  mandatory.  They  represent  desirable 
but  not  necessary  relationships;  in  other  words,  such  relationships  are  good  for  efficiency  but 
not  necessary  for  correctness.  A  priority  value  greater  than  1  is  associated  with  them  in  Table 
5.4. 

Procedure  EXTSEQ  constructs  a  graph  for  the  modfun  specification.  The  nodes  of  the 
graph  represent  simple  entities,  unlike  the  graph  for  a  test.  This  is  so  because  there  are  no 
free  subscriptsfree  subscript  associated  with  the  entities  which  are  represented  by  the  nodes. 
The  graph  is  analyzed  to  check: 

1 .  that  every  variable  node  has  a  predecessor,  i.e.  every  variable  is  defined; 

2.  that  every  variable  node  has  only  one  predecessor,  i.e.  every  variable  is  defined 
by  only  one  test  or  diagnosis; 

3.  that  a  diagnosis  does  not  precede  two  or  more  tests  with  type  2  or  3  edges,  i.e.  a 
diagnosis  does  not  select  more  than  one  test  by  the  logical  operatois  A  and  A~. 

The  next  step  is  to  detect  cycles  and,  if  possible,  eliminate  them  by  removing  edges  with 
priority  value  greater  than  1 .  They  correspond  to  preference  edges  and  are  not  essential  e  g. 
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a  failure  liklihood  edge  (type  10  priority  4)  between  two  tests  expresses  that  the  liklihood  of 
detecting  a  failure  by  the  predecessor  test  is  higher.  It  reflects  knowledge  which  may  be 
useful  for  quicker  fault  isolation,  but  is  not  mandatory  for  correct  fault  isolation. 

The  final  step  is  to  sort  the  nodes  into  a  possible  execution  sequence.  A  simple 
topological  sort  is  sufficient  because  there  are  no  free  subscripts  or  iterations.  Finally,  an 
order  vector  is  generated.  The  order  vector  is  used  by  Phase  3  to  generate  Equate  Atlas 
code. 

5.4  CODEGENERATION 

This  is  the  third  and  final  phase  which  generates  Equate  Atlas  code  corresponding  to  the 
Nopal  specification.  Code  is  generated  for  each  of  the  entities,  tests,  diagnosis,  assertions, 
conjunctions,  variables,  structures  etc.  The  order  of  execution  of  these  entities  is  determined 
in  Phase  2  in  the  form  of  an  order  vactor.  This  is  used  in  the  present  phase  in  generating  the 
sequential  program  in  Equate  Atlas. 

Eqate- Atlas  is  a  test  programming  language  and  is  a  subset  of  IEEE  standard  Atlas.  It  has 
a  number  of  features  to  support  the  programming  of  ATE.  However,  it  does  not  support  many 
of  the  widely  accepted  programming  constructs.  Mostly  notably, 

1.  The  procedures  in  Equate-Atlas  do  not  have  parameters.  The  procedure  simply 
represents  a  body  of  sequential  code  which  is  executed  when  called. 

2.  There  is  no  provision  for  local  variables  in  procedures.  All  variables  are 
considered  global. 

3.  The  if-then-efse  construct  is  absent.  It  can  be  simulated  using  "compare"  and 
"goto"  statements,  reminiscent  of  the  assembly  language  instructions. 

4.  It  does  not  have  a  do  while  costruct.  It  has  for  loop  similar  to  the  Do  loop  in 
Fortran. 

iJ 
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5.  It  does  not  have  a  linking  facility.  Consequently,  all  the  procedures  should  be 
included  in  one  program  at  compile  time.  The  procedures  communicate  by 
means  of  global  variables. 

6.  The  only  data  structuring  method  in  the  language  is  array.  Declarations  for 
records  and  structures  are  not  allowed. 

7.  The  language  has  only  two  data  types:  decimal  and  digital.  Decimal  is  used  for 
floating  point  numbers  and  digital  for  bit  strings.  There  are  no  other  data  types 
e.g.  character  strings,  integers  etc. 

8.  It  does  not  allow  dynamic  memory  allocation. 

Certain  conventions  were  established,  in  view  of  the  rather  severe  limitation  given  above. 
For  example,  to  pass  parameters  to  a  procedure,  named  say  P.  the  following  convention  was 
adopted:  The  parameters  were  passed  in  the  special  variable  names  P.PRMOl,  P.PRM02,  ... 
and  so  on.  At  the  time  of  the  procedure  call  these  parameter  variables  are  given  values.  The 
body  of  the  procedure  uses  these  names  to  receive  source  parameters  and  defines  values  of 
the  target  parameters  to  return  values. 

Lack  of  a  linking  facility  forces  that  the  Equate- Atlas  statements  generated  separately  for 
each  of  the  modules  be  put  together  and  the  resulting  total  program  be  complied  at  one  time. 
This  raises  a  problem,  however.  The  language  has  no  local  variables,  and  hence,  two 
variables  of  the  same  name  occurring  in  the  two  different  modules  would  be  treated  as  one. 
The  clash  of  the  variable  names  is  avoided  by  generating  unique  names  for  the  module.  All 
variables  in  a  module  are  suffixed  by  followed  by  the  module  name. 

The  absence  of  if  then  else  and  do-while  is  handled  using  the  p/imitives  "compare"  and 
"goto".  The  absence  of  structure  declaration  is  handled  by  simple  variables  and  arrays. 
Although,  these  make  the  generated  code  messy,  they  pose  no  conceptual  problem. 

The  code  generation  phase  consists  of  three  sub- phases.  Sub  phase  1  consists  of 
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generation  of  program  header,  declaration  for  the  global  variables  and  system  variables,  and 
a  procedure  definition  for  each  of  the  diagnosis.  Sub  phase  2  consists  of  generation  of  a 
procedure  for  each  test.  The  third  and  final  sub-phase  3  consists  of  generation  of  logic  and 
sequence  of  calls  on  procedures  for  tests  within  a  modfun.  The  procedures  for  each  of  the 
sub-phases  are  CDEMAIN,  CDETEST  and  TRMNATE  respectively.  The  highlights  of  the 
sub  phases  are  presented  below. 

In  sub  phase  1  the  declarations  for  global  variables  are  issued.  For  a  simple  variable  in  the 
Nopal  module,  a  simple  variable  by  the  same  name  (suffixed  by  the  module  name  as  described 
earlier)  is  declared  in  Equate  Atlas.  Similarly,  for  an  n-dimensional  array  variable  in  Nopal,  an 
array  with  the  same  upper  bounds  for  each  of  the  dimensions  is  declared  in  Equate  Atlas. 
There  is  an  exception,  however.  For  array  dimensions  whose  upper  bound  has  been  declared 
as  in  Nopal,  and  for  which  only  two  elements  -  current  and  the  previous  need  to  be  kept  in 
memory,  size  of  2  is  declared  in  Equate  Atlas.  The  two  elements  in  Equate  Atlas  are  used  to 
store  the  current  and  the  previous  value  of  the  elements  of  memory  and  is  part  of  the  space 
optimization  done  by  the  Nopal  processor. 

Equate  Atlas  does  not  have  any  facility  for  declaration  of  structures.  Consequently,  a 
translation  is  made:  the  fields  in  the  structures  are  declared  as  variables.  The  dimensionality 
of  the  variables  is  the  same  as  the  dimensionality  of  the  fields.  (The  dimensionality  of  a  field  is 
obtained  by  propagating  the  dimensionality  of  its  ancestor  nodes  in  the  structure,  to  the  field. 
This  is  done  by  the  procedure  XREF1 .) 

In  case  of  a  module  M  (not  the  main  module)  an  additional  dimension  is  added  to  the  fields 


of  the  record  which  gives  the  representation  for  the  abstract  data  type  M.  For  example,  in  the 
declaration  of  representation  of  a  stack 
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NOPAL  MODULE  STACK; 

DCL  1  STACK;  RECORD, 

2  TOPZ :  INTEGER, 

2  Z:  INTEGER  ARRAY(IOO); 

the  fields  TOPZ  is  declared  to  be  a  one  dimensional  array,  and  Z  a  two  dimensional  array. 
This  extra  dimension  is  added  to  allow  storage  of  all  the  variables  of  type  stack.  Similarly,  in 
the  usage  of  the  fields  of  stack,  S.TOPZ.  the  qualifier  S  becomes  an  index  which  provides  the 
reference  into  the  array  TOPZ.  All  this  became  necessary  because  the  object  language  does 
not  have  facili'  for  dynamic  memory  allocation.  In  PL/I  for  example,  the  above  could  have 
been  implemented  by  means  of  based  variables  and  pointers.  Record  STACK  with 
components,  i.e.  variable  TOPZ  and  one  dimensional  array  Z,  would  have  been  declared  as  a 
based  structure  The  qualifiers  would  simply  have  been  pointers.  There  would  be  no  need  to 
add  an  additional  dimension. 

It  follows  from  the  above  discussion  that,  in  the  current  implementation,  the  variables  of 
abstract  data  types  are  indices  to  arrays  in  the  Equate  Atlas  program  and  store  decimal 
numbers. 

Procedure  CDETEST  which  performs  sub  phase  2  is  called  at  the  end  of  sequencing  of 
each  test  in  the  intra-test  analysis  and  sequencing  CDETEST  generates  a  procedure  for  the 
test.  The  body  of  the  procedure  contains  sequential  code  corresponding  to  the  conjunctions, 
assertions,  and  logic  for  selecting  diagnoses  Statements  for  conjunctions  and  assertions  are 
generated  one  at  a  time  in  the  order  deteremined  from  the  earlier  inlra  lest  sequencing  phase. 
Iteration  statements  are  also  generated  based  on  information  about  the  name  of  the  iteration 
variable,  its  upper  bound  and  its  scope.  In  cases,  where  the  upper  bound  is  not  specified  an 
arbitrarily  large  upper  bound  is  used.  However,  the  appropriate  termination  condition  is 


generated  to  exit  the  loop. 
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In  the  case  of  input  (or  output)  structure,  calls  are  generated  on  the  ACCESS  (or  SAVE) 
functions  to  read  (or  write)  the  structure  from  (or  to)  the  appropriate  file.  Similarly,  in  case  of 
abstract  structures  of  abstract  data  type,  say  DT,  calls  are  issued  on  ACCESS.DT  or  SAVE.DT 
as  the  case  may  be. 

Finally,  sub  phase  3  generates  calls  on  the  procedures  for  the  test,  and  the  logic  which 
precedes  these  calls.  The  order  in  which  these  calls  are  generated  depends  on  the  ORDER 
vector  produced  by  the  inter-test  analysis  and  sequencing  phase.  This  sub- phase  is  not 
needed  for  modules  (except  the  main  module)  because  only  one  test  per  modfun  is  permitted 
in  the  present  implemenation. 

At  the  end  of  the  three  sub-phases,  Equate-Atlas  code  is  generated  for  a  module 
specification.  This  can  be  pul  together  with  the  code  for  other  modules,  thus  yielding  a 
complete  Equate-Atlas  program.  One  of  the  modules  must  be  a  main  module.  This  program 
can  now  be  run  on  an  Equate  Atlas  machine. 


Chapter  Six 

CONCLUSIONS  AND  FUTURE  WuRK 


6.1  SUMMARY 

This  dissertation  presents  the  approach  of  abstract  data  types  to  introduce  modularity  in 
non  procedural  languages.  It  introduces  the  notion  of  module  for  the  specification  of  an 
abstract  data  type  in  a  non  procedural  language  based  on  equational  specification.  A  module 
specification  can  be  analyzed  for  consistency,  completeness  and  non  ambiguity  independent 
of  other  modules.  It  allows  abstract  data  types  to  be  specified  independent  of  their  use.  The 
concept  of  module  is  general  enough  to  allow  the  specification  of  recursive  data  types. 

A  simple  equational  language  is  introduced,  and  the  least  fix  point  semantics  of  modules  is 
presented.  It  is  shown  by  means  of  an  example  how  a  data  type  specified  by  a  module 
satisfies  certain  algebraic  axioms. 

Nopal,  a  non  procedural  language  designed  for  automatic  tes  ng  of  physical  systems  is 
used  as  an  example  to  show  the  feasibility  of  the  use  of  abstract  data  types.  Nopal  language 
allows  abstract  data  types  to  be  specified  by  means  of  modules.  The  data  types  once 
specified  can  be  used  in  other  modules. 

A  complete  implementation  of  the  Nopal  program  generator  is  described  in  brief.  A 
number  of  examples  and  their  sample  runs  are  given  in  the  Appendix.  The  program  generator 
analyzes  the  specification  and  generates  an  efficient  program  in  Equate-Atlas  satisfying  the 

specification.  Optimization  for  memory  and  execution  time  is  done  in  the  generated  program. 
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The  use  ot  abstract  data  types  allows  relations  to  be  specified  between  variables  which  are 
not  just  of  elementary  type,  but  are  of  arbitrary  type  It  allows  a  data  type  to  have  an  arbitrary 
degree  of  complexity  hidden  away  in  the  module  and  shielded  from  its  use.  This  is  of 
particular  advantage  in  decomposition  of  the  problem  It  allows  operations  on  larger  units  of 
data,  ignoring  lot  of  detail,  in  the  process  When  these  large,  units  of  data  correspond  to 
some  concept  naturally  occurring  in  the  problem  domain  (e  g.  stacks  and  tokens  while 
parsing  a  string  in  a  formal  language)  the  specification  is  written  in  terms  of  these  concepts.  It 
also  allows  devices  in  automatic  testing  to  be  treated  as  data  types. 

Procedures  or  subroutines  are  procedural  abstraction  in  the  conventional  programming 
languages.  They  represent  a  form  of  abstract  action  which  fits  well  with  the  prescriptive  style 
of  programming.  In  non  procedural  languages,  on  the  other  hand,  the  relationships  between 
variables  is  the  building  block.  Use  of  abstract  data  types  allows  the  variables  to  be  used  and 
their  values  defined  free  of  the  details  of  the  arbitrarily  complex  data  structure  that  they  might 
represent.  It  is  felt  that  just  as  the  procedures  are  a  natural  way  to  introduce  modularity  in 
procedural  language,  the  abstract  data  types  are  a  natural  way  to  introduce  modularity  in 
non  procedural  languages. 

A  most  important  feature  of  the  introduction  of  the  abstract  data  types  in  the 
non  procedural  language  has  been  that  it  does  not  lead  to  a  change  in  semantics  of  the 
non  procedural  language.  This  is  in  contrast  to  procedural  languages  where  an  abstract  data 
type  facility  has  led  to  an  obiect  oriented  semantics  e  g.  CLU  (Section  2  2),  vhich  is  different 


from  conventional  and  generally  accepted  value  oriented  semantics. 
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6.2  FUTUREWORK 

Work  needs  to  be  done  in  two  areas  to  make  the  abstract  data  types  easy  to  use  in 
non  procedural  languages: 

1.  Efficiency  of  the  generated  program  should  be  improved  upon,  and 

2  Additional  extensions  should  be  made  to  the  language. 

Some  of  the  problems  are  outlined  below. 

6.2.1  EFFICIENCY  CONSIDERATIONS 

In  the  current  implementation.  Nopal  processor  does  the  following  memory  optimization:  If 
an  array  variable  is  declared  to  be  of  dimension  and  is  used  such  that  only  the  current  and 
the  previous  element  of  the  array  is  needed,  then  the  memory  allocated  for  the  array  is  equal 
to  two  elements.  This  is  of  great  value  when  the  array  is  an  input/output  structure  a.-d 
represents  a  big  file  on  secondary  storage.  The  above  should  be  extended  to  not  just  2  but  k 
elements  of  an  array  variable  (where  k  is  an  integer).  It  should  be  determined  v/hen  a 
constant  storage,  k,  may  be  used  in  the  generated  program  automatically  without  having  the 
user  to  declare  it.  This  is  part  of  ongoing  research  by  Mr.  K.S.  Lu  [36]  to  generate  efficient 
programs  from  a  non  procedural  specification  (and  is  independent  of  the  use  of  abstract  data 
types) 

Modularity  makes  some  of  the  optimizations  impossible  at  program  generation  time.  For 
example,  in  the  generated  program  for  the  specifiaton  of  an  abstract  data  type  storage  is 
allocated  for  the  representation  of  each  of  the  variables  of  abstract  data  type  Even  when 
some  of  the  variables  are  not  needed  at  the  same  time,  memory  optimization  cannot  be  done 


at  the  program  generation  time,  since  the  use  of  the  abstract  data  type  is  independent  from  its 
specification,  and  the  corresponding  information  is  not  avalable  at  the  lime  the  program  is 
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generated  from  the  specification. 

A  possible  way  to  reuse  the  memory  which  is  no  longer  needed  is  to  do  garbage  collection. 
Any  one  of  the  well  known  techniques  can  be  used  [31]  to  provide  better  utilization  of 
memory. 

6.2.2  LANGUAGE  EXTENSIONS 

The  data  typing  facility  described  here  can  be  extended  in  many  ways  to  improve 
compactness,  clarity  etc.  To  give  an  example:  The  language  should  permit  (and  the 
implementation  should  support)  the  specification  of  "parameterized"  data  types  By  this  it  is 
meant  that  the  specification  of  the  abstract  data  types  contains  a  data  type  as  a  parameter. 
For  instance,  it  should  permit  the  specification  of  a  stack  of  type  T.  where  T  can  be  integer, 
character,  stack  etc.;  and  is  specified  with  the  use  of  the  generic  stack  This  would  allow  a 
single  stack  specification  to  represent  the  various  types  of  stack  and  lead  to  compactness  as 
well  as  economy  of  names  of  data  types  and  their  modfuns. 

Non  procedural  specification  should  be  investigated  in  the  light  of  distributed  processing. 
The  applicative  nature  of  the  language  is  ideally  suited  for  detection  of  parallelism  within  a 
module.  The  array  graph  can  be  directly  translated  into  a  parallel  program  Research  needs 
to  be  conducted  to  allow  different  modules  to  execute  on  different  processors  and 
communicate  with  each  other. 


Appendix  A 

EXAMPLES  OF  NOPAL  SPECIFICATIONS 


Some  example  specification  s  are  given  here.  Sample  runs  for  specification  of  stack 
together  with  a  complete  set  of  reports  generated  by  the  Nopal  processor  are  given  in  the  first 
section.  The  sections  which  follow,  contain  other  example  specifications  with  sequencing 
report  for  each  of  the  specifications. 
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A.1  STACK 

Nopal  specification  for  stack  is  given  in  this  section.  Nopal  module  STACK  defines  a 
representation  consisting  of  TOPZ  and  Z.  It  is  followed  by  a  specification  of  the  functions 
PUSH,  POP,  TOP,  and  EMPTYSTACK  which  can  operate  on  stacks.  Each  function  implicitly 
has  a  test  and  is  specified  by  means  of  assertions.  The  assertions  specify  relationships 
between  the  input  and  output  parameters  of  the  function.  For  example,  in  statement  number 
6  (which  is  an  assertion  in  modfun  PUSH)  value  of  TOPZ  component  of  stack  Si  is  specified 
in  terms  of  the  value  of  TOPZ  component  of  stack  S  (where  Si  is  the  output  parameter,  and  S 
the  input  parameter  of  PUSH).  The  stack  has  been  discussed  quite  extensively  in  Chapter  3 
and  the  various  assertions  are  not  discussed  any  further  here.  Since  a  logic  component  must 
be  associated  with  a  test  in  Nopal,  a  dummy  diagnosis  is  specified.  Similarly,  since  the 
assertions  must  be  part  of  stimuli  or  measurements,  the  assertions  have  been  arbitrarily 
placed  under  stimuli  in  each  of  the  modfuns. 

A  sequencing  report  is  generated  for  each  of  the  functions  by  the  Nopal  processor.  It 
consists  of  weighted  adjacency  matrix  representing  the  array  graph;  followed  by  an  order 
vector  which  represents  an  ordering  of  the  nodes  of  the  graph  The  order  vector  determines 
the  sequence  in  which  Equate-atlas  code  is  generated  for  the  module  Equate  Atlas  code  is 
given  after  the  sequencing  report.  It  is  followed  by  a  cross  reference  and  attribute  report,  and 


warning  meseages. 
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A. 2  ACKERMANN'S  FUNCTION 

Nopal  specification  which  specifies  Ackermann’s  function  is  given  in  this  section. 
Ackermann’s  function  as  expressed  by  recursive  equations  is: 

A(0,n)  =  n  + 1  (A- 1 ) 

A(m,0)  =  A(m  1,1)  (A- 2) 

A(m,n)  =  A(m-1  ,A(m,n-1))  (A-3) 

Nopal  specification  is  based  on  the  simulation  of  function  calls  by  means  of  a  stack.  It  is 
convenient  to  imagine  that  there  is  an  array  V  of  stacks,  which  is  represented  in  the 
specification  by  arrays  TOP,  LBO,  and  S.  An  element  V(l)  of  the  array  of  stacks  is  represented 
by  LAST(I)  which  gives  the  top  of  the  stack  V{l),  LBO(I)  which  gives  the  second  element  of  the 
stack,  and  S(l)  which  gives  the  rest  of  the  stack. 

COMPUTE  specifies  the  computation  of  the  value  of  Ackermann’s  function  with  arguments 
M,  N.  To  begin,  values  of  M  and  N  are  placed  on  the  stack  with  N  being  on  the  top;  this  is  done 
by  defining  the  value  of  LAST(1)  to  be  equal  to  N,  the  value  of  LBO(1)  equal  to  M,  and  the 
value  of  S(1)  to  be  a  stack  with  a  special  symbol  -1  signifying  the  bottom  of  the  stack  V(1). 
Top  two  elements  of  the  stack  V,  always  contain  the  arguments  for  which  Ackermann’s 
function  needs  to  be  computed  at  any  point  in  execution.  Finally,  a  single  value  is  left  on  the 
stack,  and  that  gives  the  value  of  Ackermann’s  function  for  arguments  M,  N  The  assertions 
given  by  statements  15, 16,  and  17  can  now  be  explained  as  follows: 

If  the  top  element  of  stack  V(l-1),  i.e.  LAST(M),  is  equal  zero  then  it  corresponds  to 
Equation  A-2.  The  top  two  elements  (p,0)  of  stack  V(l  1)  should  be  replaced  by  (p  1,1).  This  is 
accomplished  in  the  specification  by  defining  LAST(I)  to  be  1,  LBO(I)  to  be  (LBO(I-I)  •  1),  and 
S(l)  to  be  S(l-1). 

Similarly,  if  the  second  element  (from  the  top)  of  the  stack  V(l  1)  is  zero,  it  corresponds  to 


I 

I 
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Equation  A  1,  and  the  Ackermann’s  function  for  the  top  two  elements  of  the  stack  evaluates  to 
one  plus  the  top  element  of  the  stack.  This  means  popping  the  stack  twice,  and  pushing  the 
new  value  on  the  stack.  Thus  in  the  specification,  if  LBO(M)  is  zero  then  LAST(I)  is  equal  to 
(LAST(I)  +  1),  LBO(I)  is  equal  to  TOP(S(l-1)),  and  S(l)  is  equal  to  POP(S(l-1)). 

Finally,  if  it  is  none  of  the  above  two  cases,  action  corresponding  to  the  RHS  of  Equation 
A  3  is  carried  out. 

After  the  specification,  sequencing  reports  are  included;  they  are:  inter  test  and  intra  test 
sequencing  reports.  Inter  test  sequencing  report  shows  that  the  test  INIT  should  be 
performed  before  the  test  COMPUTE.  Intra  test  reports  contain  sequencing  of  tests  INIT  and 


COMPUTE. 
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A.3  BAND-WIDTH  METER 

The  main  module  BWM  specifies  the  application  of  a  voltage  source  with  frequencies  in  a 
range  with  a  given  step  size  to  a  UUT.  For  each  application  of  a  frequency,  the  gain  of 
voltages  (ratio  of  output  voltage  to  input  voltage)  across  the  UlIT  is  measured.  A  table 
corresponding  to  the  applied  frequencies  and  the  measured  gains  is  printed  out.  The  devices 
are  represented  by  means  of  abstract  structures:  gain  measurement  device  is  represented  by 
the  structure  GD,  and  frequency  source  by  the  structure  FS.  A  call  is  issued  to 
ACCESS.GAIN  DEVICE  whenever  the  value  of  GAIN,  a  field  in  the  structure  GD,  is  accessed 
(before  statement  24);  and  similarly,  a  call  is  issued  to  SAVE.FREO  SOURCE  in  the  case  of 
structure  FS  (after  statements  16,  17,  and  18).  The  assertions  in  the  specification  are  self 


explanatory. 
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The  specification  for  GAINDEVICE,  given  below,  has  only  one  modtun  called 
ACCESS.GAIN.DEVICE.  The  modfun  takes  voltage  measurements  across  pins  (11,12)  and 
(13,14).  The  ration  of  the  two  measurements  defines  the  value  of  GAIN.  It  depends  on  two 
funtions:  VOLTMETER  and  MICROVOLTMETER  to  take  the  actual  measurements. 


iniaa  Ttsi  sesuencins  access  sain 
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The  specification  for  FREQ.SOURCE  defines  a  function  SAVE.FREO.SOURCE  which 
specifies  the  application  of  a  frequency  source  by  means  of  the  function  FREQ  GEN.  The 
voltage  and  frequency  to  be  applied  are  specified  by  the  input  parameters.  An  error  is  issued 
if  the  parameters  specify  a  frequency  which  falls  out  of  range  of  the  instrument. 
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A.4  FILEINPUT-OUTPUT 

This  example  illustrates  the  updating  of  an  inventory  file,  named  INV,  based  on 
transactions  contained  in  a  sequential  file,  called  TRANS.  A  record  in  TRANS  has  two  fields: 
KEY  and  an  array  A,  A  record  in  INV  is  found  corresponding  to  the  KEY  in  each  of  the  records 
in  TRANS  and  is  updated  based  on  the  sum  of  the  corresponding  array  A.  General  functions 
ACCESS  and  IACCESS  are  used  to  read,  and  SAVE  and  ISAVE  to  store,  records  from  SAM 
and  ISAM  files  respectively. 

Corresponding  sequence  reports  and  Equate  atlas  code  are  given  after  the  specification. 


f  NOPAL  TEST  SPECULATION  SOURCE  INPUT 
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fUNC  S  UM  ,  T  IP  E  3  6 ; 

END  10; 
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